Burndown Chart
Artifacts
Product Backlog
The product backlog is a high-level list that is maintained throughout the entire project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an absolute ordering by business value. It is therefore the “What” that will be built, sorted by importance. It is open and editable by anyone and contains rough estimates of both business value and development effort. Those estimates help the Product Owner to gauge the timeline and, to a limited extent prioritize. For example, if the “add spellcheck” and “add table support” features have the same business value, the one with the smallest development effort will probably have higher priority, because the ROI (Return on Investment) is higher.
The Product Backlog, and business value of each listed item is the property of the product owner. The associated development effort is however set by the Team.
Sprint Backlog
The sprint backlog is the list of work the team must address during the next sprint. Features are broken down into tasks, which, as a best practice, should normally be between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. This promotes self-organization of the team, and developer buy-in.
The sprint backlog is the property of the team, and all included estimates are provided by the Team. Often an accompanying task board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
Burn Down
The sprint burn down chart is a publicly displayed chart showing remaining work in the sprint backlog. Updated every day, it gives a simple view of the sprint progress. It also provides quick visualizations for reference. There are also other types of burndown, for example the release burndown chart that shows the amount of work left to complete the target commitment for a Product Release (normally spanning through multiple iterations) and the alternative release burndown chart, which basically does the same, but clearly shows scope changes to Release Content, by resetting the baseline.
The Process
Sprint Planning
At the beginning of the sprint cycle (every 7–30 days), a “Sprint Planning Meeting” is held. The exact length of each sprint should be determined by the Team, and should be relative to things like Project Timelines, Deliverable Due Dates, and how much time is required to complete tasks. This meeting is designed to preform the following tasks:
- Select what work is to be done
- Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
- Identify and communicate how much of the work is likely to be done during the current sprint
- Eight hour time limit
- (1st four hours) Product Owner + Team: dialog for prioritizing the Product Backlog
- (2nd four hours) Team only: hashing out a plan for the Sprint, resulting in the Sprint Backlog
Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a “daily scrum”, or “the daily standup”. This meeting has specific guidelines:
- The meeting starts precisely on time.
- All are welcome, but only “pigs” may speak
- The meeting is time boxed to 15 minutes
- The meeting should happen at the same location and same time every day
During the meeting, each team member answers three questions:
- What have you done since yesterday?
- What are you planning to do today?
- Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to facilitate resolution of these impediments. Typically this should occur outside the context of the Daily Scrum so that it may stay under 15 minutes.)
At the end of a sprint cycle, two meetings are held: the “Sprint Review Meeting” and the “Sprint Retrospective”
Sprint Review
- Review the work that was completed and not completed
- Present the completed work to the stakeholders (a.k.a. “the demo”)
- Incomplete work cannot be demonstrated
- Four hour time limit
Sprint Retrospective
- All team members reflect on the past sprint
- Make continuous process improvements
- Two main questions are asked in the sprint retrospective:
- What went well during the sprint?
- What could be improved in the next sprint?
- Three hour time limit
Finishing Comments
Although there are many variations of this basic process, these are the items they all have in common. So now you may ask yourself why this is… The answer is really simple, because it works. When this process is adhered to, and the principals followed, this process just works. It allows Teams to deliver better software, faster. It delivers software that meets the needs of the consumers, while eliminating a lot of the waste, and lost time, normally associated with software development. While this is not a “Magic Bullet”, designed to fix every issue, it offers an approach that is readily adaptable to the changing needs customers often face. It can be extremely flexible and able to address requirements as they change.
