Improve burndown charts with taking estimated and spend time into account
Problem to solve
In a small scrum team with a short iteration period (2 weeks) the burndown chart often shows inaccurate data because an issue that has a high time estimate (i.e. 40 hours and 35 already spend) but is nearly finished is shown exactly the same in the burndown chart as a not yet started issue.
Also issues that are done (moved from label To Do to Done in the Issue board) are considered open. This can be problematic because the actual work of the scrum team is done but not merged yet (the merge request would close the issue). So a team has either to choose between Closed means an issue is merged or Closed means the developer has done his work and the issue is still awaiting merging.
Intended users
Scrum masters and everybody working with the burndown chart in general
User experience goal
Scrum masters should be able to see a better burndown chart value that takes time spend into account
Proposal
I want to see a burndown chart based on the percentage of work done (estimate - time spend) instead of number of issues / issue weight.
Since there might be issues with would have an estimate and spend value and others won't I would not go so far to look at the actual hours for burndown value calculation.
A much simpler approach would be to calculate a percent completed value every time an issue gets updated.
- Issue is open, no estimate, no time spend: 0%
- Issue is open, no estimate, time spend 5h: 0%
- Issue is open, estimate 10h, time spend 5h: 50%
- Issue is open, estimate 10h, time spend 15h: 100%
- Issue is closed: 100% (regardless of the estimate / time spend)
- Bonus: Issue has one of some defined labels (i.e. Done / Waiting for Approval / QA): 100%
In the burndown chart a issue that is done 50% could be shown accordingly. A milestone with 10 issues that are all 50% completed should yield the same result as 10 issues where 5 are closed would do in the current burndown chart.
I don't know how the calculations to plot the data is done internally but I guess
- For burndown based on issues every issue gets a value of 1
- For burndown based on issue weight the real weight is assumed and issues without a weight are either ignored or get an average value
If this value would be multipled by the percentage completed this should already be sufficient to get the desired results without changing to much of the logic itself.
The feature could be
- enabled by default
- enabled in settings
- or even enabled by a choosing a different view in the burndown chart
What does success look like, and how can we measure that?
In a milestone with a start to end period of one month, after two weeks with plenty of work done you should still be able to see if you are on time or over time (graph is below or above the guideline) in your current iteration even if no issues have been closed yet.