Scrum Artefacts

Product Backlog

The Product Backlog is an ordered list of everything that might be needed in the product and is the single source of requirements for any Changes to be made to the product. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. It contains broad descriptions of all required features, functions, enhancements, wish-list items, etc. The Product Backlog defines the “What” that will be built.

As Increments are being reviewed and releases of the product are being used, feedback is provided and the Product Backlog emerges into a larger, more exhaustive and more detailed list. The Product Backlog items are initially established and calculated during Release Planning. Afterwards they are updated in Sprint Planning. This is typical format for product backlog. To trace user stories they may be linked to themes and epics as per project. In sprint review meeting the team estimates the effort required to implement the top Stories in the Product Backlog, and the Scrum Master moves Stories into the Sprint Backlog, until the team’s capacity for the Sprint has been filled up.

Sprint Backlog

The Sprint Backlog is the set of Stories planned for implementation in a Sprint (the “Sprint” being the standard 2—4 week development period). The Stories in the Sprint Backlog must be ranked in the desired order of implementation (a Product Owner responsibility). The ranking reflects both the urgency (value) of the story, and any dependencies that exist between stories. As mentioned, in sprint review meeting the team estimates the effort required to implement the top Stories in The Product Backlog, and the Scrum Master moves Stories into the Sprint Backlog, until the team’s capacity for The Sprint has been filled up. Often represented with an “information radiator” such as a task board

The Sprint Backlog is property of the Team. Estimations are set by the Development Team. The Team keeps the Sprint Backlog always up to date during the Sprint. As the work is done, the Development Team may find that more, less or different tasks are needed. Often a Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done.

Sprint Burn down Chart

As a definition of this chart we can say that the Burn down chart displays the remaining effort for a given period of time. The source of the raw data is the sprint backlog. The horizontal axis shows days in a sprint, and the vertical axis measures the amount of work that remains to complete the tasks in the sprint. The work that remains is shown in hours. The release burn down chart is updated at the end of each sprint by the Scrum Master. Burn down answers following questions

• How fast is the team completing remaining work?

• Is the team adding work during the iteration? Is there scope creep?

• How much work can the team complete in the available time?

• When can the team finish the work?

• When can the team finish the current iteration?

In the burn-down chart, the team worked at a slow pace in the first few weeks of the sprint, and pushed towards the end of the sprint to meet the commitment. To update the burn down chart, each member picks up tasks from the task breakdown and works on them. At the end of the day, they update effort remaining for the task, along with its status. Since its inception, many variations of burn-down have appeared. The Cumulative Flow Diagram (CFD) is another popular tool that provides a greater level of detail and insight into various stages of a task or story. However, recent studies show that burn-down charts remain the most popular tracking tool for agile practitioners, Due to their effectiveness and simplicity.

Burn up Charts

A burn up chart, tracks progress towards a projects completion. In a burn up chart the vertical axis represents the amount of work, and is measured in units customized to your own project. Some common units are number of tasks, estimated hours or story points (in agile project management methodologies) and the horizontal axis represents time, usually measured in days. At each day you can see the amount of work completed and the total amount of work. The distance between the two lines is the amount of work remaining. When the two lines meet, the project will be complete.

This is a powerful measure of how close you are to completion of the project is the only difference between burn up and burn down is that instead of tracking how much work is left to be done, we track how much work we’ve completed, so the curve is going up, not down. A burn up chart clearly shows work completed and project scope. It is an effective tool for communicating to the project stakeholders and clients how the extra feature requests they are asking for will affect the deadline, and at the same time for reassuring them that good progress is being made.

In a project where clients are adding a lot of work mid-project, a burn down chart will not be an accurate reflection of the project teams output, and could lead to performance questions from the client. A burn up chart can quickly make clients.