One tool of an agile management system is the sprint backlog, which is a list of requirements and tasks in a given sprint. The sprint backlog is updated every day of the sprint. Make the sprint backlog available to the entire project team every day. That way, anyone who needs to know the sprint status can find it instantly.
A sprint burndown chart (sample shown) shows the progress the development team is making and is a powerful tool for visualizing progress and the work remaining. The chart shows:
The outstanding work (in hours) on the first vertical axis
Time, in days, along the horizontal axis
Some sprint burndown charts also show the outstanding story points on a second vertical axis plotted against the same horizontal time axis as hours of work remaining.
A burndown chart enables anyone to see the status of the sprint at any time. Progress is clear. By comparing the realistic number of hours available to the actual work remaining, you can find out daily whether the effort is going as planned, is in better shape than expected, or is in trouble. That information helps you determine whether the development team is likely to accomplish the targeted number of user stories and helps you make informed decisions early in the sprint.
Looking at samples of burndown charts for sprints in different situations, you can tell how the work is progressing:
Expected
This chart shows a normal sprint pattern. The remaining work hours rise and fall as the development team completes tasks, ferrets out details, and identifies tactical work it may not have initially considered. Although work occasionally increases, it is manageable, and the team mobilizes to complete all user stories by the end of the sprint.
More complicated
In this sprint, the work increased beyond the point in which the development team felt it could accomplish everything. The team identified this issue early, worked with the product owner to remove some user stories, and still achieved the sprint goal. The key to scope changes within a sprint is that they are always initiated by the development team — no one else.
Less complicated
In this sprint, the development team completed some critical user stories faster than anticipated and worked with the product owner to identify additional user stories it could add to the sprint.
Not participating
A straight line in a burndown means that the team didn't update the burndown or made zero progress that day. Either case is a red flag for future problems.
Lying (or conforming)
This burndown pattern is common for new agile development teams used to reporting the hours management expects instead of the time the work really takes. A team with this chart likely adjusted its work estimates to the exact number of remaining hours. This pattern often reflects a fear-based environment, where the managers lead by intimidation.
Failing fast
One of the strongest benefits of agile is the immediate proof of progress, or lack thereof. This pattern shows an example of a team that wasn't participating or progressing. Halfway through the sprint, the product owners cut their losses and killed the sprint. Only product owners can end a sprint early.
The sprint backlog helps you track progress throughout each sprint. You can also refer to earlier sprint backlogs to compare progress from sprint to sprint. You will make changes to your process in each sprint. Constantly inspect your work and adapt to make it better.