Menu
There are several ways to do burn down charts in Scrum.
Some people suggest using the story points of unfinished stories left as your burn down charts in Scrum.
Pro: Only finished stories lower the chart
Contra: Chart doesn't move down in the beginning and then rapidly falls off
Others suggest to use the number of tasks left
Pro: Chart will move down, you can see if it is above the finishing line
Contra: You could move down to say 10 tasks left (hard tasks) in the end, and still have not one story finished. You've failed because only finished strories are good for your product owner.
Is the solution to have both a points-of-not-finished-stories and a not-finished-task chart?
717
A burndown chart shows the amount of work that has been completed in an epic or sprint, and the total work remaining. Burndown charts are used to predict your team's likelihood of completing their work in the time available. They're also great for keeping the team aware of any scope creep that occurs.
There are two types of burndown charts: Agile burndown charts and sprint burndown charts. An Agile burndown chart is used by Agile teams to enable tasks to move quickly. A sprint burndown chart is used by development teams when working in short sprints.
Story Points are counted for the total points you have committed to achieve at the start and at any point during the sprint versus the total points you actually achieved at the end of the sprint. So for e.g. You start the sprint and start of with 20 points, and then later add 5 more story points to it.
The horizontal axis of the sprint burndown chart represents the days within a sprint, whereas the vertical axis represents the remaining estimated effort-hours. The chart should be updated every day to exhibit the total estimated effort remaining across all the uncompleted tasks.
We are using remainig time for sprint burndown - teams can see progress every day. If there are flat parts, than they really occured.
In the release burndown we are using story points. Release planning is more about he feature completness, the time is tracked on the sprint level. Product owner is interested in completed stories.
Number of tasks is useless. This number can be changed every day, especially if you give a "freedom" to developers. They can split the task to smaller part without the change of the total time. Such statistic is useless. What is it indicating? Does it affect the goal of the sprint?
174
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
