Glossary of terms used on this siteThere are 9 entries in this glossary.
There are three essential roles in any Scrum project:
The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster works to assist both the team and product owner in the following ways:
Remove the barriers between the development and the product owner so that the product owner directly drives development.
Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum.
Improve the lives of the development team by facilitating creativity and empowerment.
Improve the productivity of the development team in any way possible.
Improve the engineering practices and tools so that each increment of functionality is potentially shippable.
Keep information about the team's progress up to date and visible to all parties.
Source: Agile Project Management with Scrum, Ken Schwaber
An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint.
The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint retrospective meeting.
During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.
Out of practical necessity, some teams choose to bend this rule by declaring some team members 80 percent available at the outset so they still have some cycles left for "Priority One" bugs and emergencies. But this is a slippery slope and should be avoided whenever possible.
|Sprint Burndown Chart||
A sprint burndown chart (or "sprint burndown graph") depicts the total task hours remaining per day. This shows you where your team stands regarding completing the tasks that comprise the product backlog items that achieve the goals of the sprint. The X-axis represents days in the sprint, while the Y-axis is effort remaining (usually in ideal engineering hours).
To motivate the team, the sprint burndown chart should be displayed prominently. It also acts as an effective information radiator . A manual alternative to this is a physical task board .
Ideally the chart burns down to zero by the end of the sprint. If the team members are reporting their remaining task hours realistically, the line should bump up and down chaotically. The profile shown below is typical, and demonstrates why the "percentage done" concept of traditional project management breaks down. Assuming we started measuring on July 26, what "percentage done" were we on July 28?
Sprint goals are the result of a negotiation between the product owner and the development team. Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8."
Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.
Have your team commit to goals that anyone will be able to see are met (or not met) at the end of the sprint. At sprint review meetings, the sprint demonstration is conducted after which the team asks the product owner whether (s)he feels the goals were met.
While some specific product backlog items may not be done at the end of a sprint, it should be very unusual for a team not to meet its sprint goals. Scrum requires the team to notify the product owner as soon as it becomes aware it will not meet its goals.
|Sprint Planning Meeting||
The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours.
Typically the team will then excuse the product owner from the room and break the backlog Items down into tasks. The product owner is expected to be on call during this phase (previously called the sprint definition meeting) for renegotiation or to answer questions that affect the time estimates. This portion of the sprint planning meeting is time-boxed to four hours. Sometimes teams insert placeholder tasks (with rough estimates) for the product backlog items they don't expect to start working until later in the sprint.
|Sprint Retrospective Meeting||
The sprint retrospective meeting is held at the end of every sprint after the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting.
The sprint retrospective should be time-boxed to three hours.
Kelley Louie (Certified Scrum Practitioner) writes: "The sprint retrospective meeting is an integral part of the inspect and adapt process. Otherwise, the team will never be able to improve their overall output and not focus on the overall team performance. The ScrumMaster must pay attention to this meeting and work towards resolving the impediments that may be slowing down the team."
In Scrum, a sprint task (or task) is a unit of work generally between four and sixteen hours. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.
Scrum literature encourages splitting a task into several if the estimate exceeds twelve hours.