There are three artifacts in Scrum,
The Product Backlog, the Sprint Backlog and the Burndown Chart
The Product Backlog is a list for all the requirements. These are high level user stories that features descriptions, all of which have business value priorities. The product backlog is constantly changing. The Product Owner owns this backlog, he or she will gather feedback, suggestions and additional requirements from stakeholder to add to the backlog. In other types of project management methodologies, there are heavy requirement documents, technical specs, etc. Fortunately with Scrum, the Product Backlog replaces these and the agility is well used with the ability to easily adjust the content of this.
A typical Scrum backlog comprises the following different types of items:
- Technical work
- Knowledge acquisition
Conceptually, the team starts at the top of the prioritized Scrum backlog and draws a line after the lowest of the high-priority items they feel they can complete. In practice, it’s not unusual to see a team select, for example, the top five items and then two items from lower on the list that are associated with the initial five.
The Sprint Backlog is a subset of the Product Backlog. This is the repository of the highest priorities deemed by the Product Owner. These requirements are broken out into tasks, estimated, and clearly defined by the Scrum Team. Once we start a Sprint, the Sprint backlog does not change.
The sprint backlog is commonly maintained as a spreadsheet, but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile.
An example of a sprint backlog in a spreadsheet looks like this:
The Burndown Chart is a chart that indicates how much work is remaining in the Sprint. This chart is hung up in an area that everyone can easily see, including the Scrum Team, the Product Owner and Management. This is updated on a daily basis by the ScrumMaster, after hearing from the team what they have accomplished in the Daily Scrum Meeting.
Let’s take an example using the sprint burndown chart above. As you can see, the team in this scenario pulled in too much work initially into the sprint backlog, and still had nearly 250 hours to go on day 8 of a 21-day sprint. The product owner was consulted and agreed to remove some user stories from the sprint. This resulted in the drop on the chart between days 7 and 8. We can also see that on day 8 they had completed nearly 35 tasks. From there, the team made consistent progress and finished the Scrum sprint successfully.