Glossary of terms used on this siteThere are 21 entries in this glossary.
Burndown charts show work remaining over time. Work remaining is the Y axis and time is the X axis. The work remaining should jig up and down and eventually trend downward.
|Daily Scrum Meeting||
A fifteen-minute daily meeting for each team member to answer three questions:
"What have I done since the last Scrum meeting? (i.e. yesterday)"
"What will I do before the next Scrum meeting? (i.e. today)"
"What prevents me from performing my work as efficiently as possible?"
The ScrumMaster ensures that participants call sidebar meetings for any discussions that go too far outside these constraints.
The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
Anything that prevents a team member from performing work as efficiently as possible is an impediment. Each team member has an opportunity to announce impediments during the daily Scrum meeting. The ScrumMaster is charged with ensuring impediments get resolved. ScrumMasters often arrange sidebar meetings when impediments cannot be resolved on the spot in the daily Scrum meeting.
The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog.
During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.
|Product Backlog Item|
|Product Backlog Item Effort||
Some Scrum practitioners estimate the effort of product backlog items in ideal engineering days, but many people prefer less concrete-sounding backlog effort estimation units. Alternative units might include story points, function points, or "t-shirt sizes" (1 for small, 2 for medium, etc.). The advantage of vaguer units is they're explicit about the distinction that product backlog item effort estimates are not estimates of duration. Also, estimates at this level are rough guesses that should never be confused with actual working hours.
Note that sprint tasks are distinct from product backlog items and task effort remaining is always estimated in hours.
|Product Burndown Chart|
|Product Owner Role|
The transition of an increment of potentially shippable product from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it.
"The product is released to customer or marketplace obligations. The release balances functionality, cost, and quality requirements against date commitments." (Schwaber/Beedle, Agile Software Development with Scrum, p. 80).
|Release Burndown Chart|
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?