I do not understand why the burndown is looking like it is. Remaining work is higher than capacity - but in the details remaining work is lower than remaining capacity.
Can anyone help?
-
The burndown chart gets updated at the end of the day, the work details are updated as and when the 'Remaining Hours' in a task is updated.– Shaunak LawandeCommented Feb 25, 2020 at 7:37
-
Minor deviations are expected in such charts, which are just "early warning systems." If you aren't on track to meet the Sprint Goal, then it's worth discussing with the team whether work will burn down faster later in the Sprint or if scope or Sprint Backlog items needs to be renegotiated to re-align with capacity and rate of progress towards the Sprint Goal.– Todd A. Jacobs ♦Commented Oct 18, 2023 at 16:01
Add a comment
|
3 Answers
Analysis
I'm not sure where this data is coming from, so this is only an educated guess. However, it looks like your burn-down is correctly showing that you have more development work than originally planned. Depending on your system, this can happen if:
- New work is discovered during the iteration, and added to the Sprint Backlog.
- You're tracking hours spent rather than tasks/stories done, and hours spent exceed the original estimate.
In this case, it looks like the latter. Your team estimated 39 hours for "development" (whatever that means to them), but has expended 41 hours on those activities so far.
Potential Next Steps
First of all, this may or may not be a problem. If your implementation provides sufficient slack to handle minor perturbations, then a few hours one way or another won't really matter. However, if enough work is being added that the Sprint Goal is in jeopardy, or if the projection shows that essential work will no longer fit within the current iteration, then a discussion with the team (including the Product Owner) should take place as soon as possible.
You might also consider that tracking task time consumed may be an anti-pattern, especially if it's not yielding useful information for your team. A related answer discusses the use of Trello to track story points consumed, which looks quite similar to your current time-based approach. Another answer provides a different take on why time-based tracking may be a poor measure of work remaining, and some options for addressing that.
In any case, remember that your goal in Scrum is not to make pretty graphs that follow an ideal trendline. The burn-down chart is an information-gathering and information-radiating tool, not a core deliverable. Instead, the team should use the burn-down data as a means to surface unexpected impediments within the current process, and as a conversation-starter for the whole team (including developers, Scrum Master, and Product Owner) to communicate more effectively with each other about what's really going on within the Sprint.
answered Oct 19, 2018 at 21:47
-
1I know how do do Scrum, But thanks. We do not track work done, only remaining work - that's not an antipattern. I am just trying to understand why the numbers and the graph don't match - or what i don't understand.– stulsterCommented Oct 22, 2018 at 12:23
-
@stulster You can't track "work remaining" unless you're also checking off "work completed" as you go. So, you actually have to do both. And since all Sprint Backlog items aren't necessarily the same size, burn-down and burn-up charts can (and often are) bumpy as work is only "burned" when it's completed, and items take more or less time than others. Assuming you've been tracking velocity properly over time, minor deviations are expected and will even out. All you should care about is whether you can still meet the Sprint Goal by the end of the Sprint.– Todd A. Jacobs ♦Commented Oct 18, 2023 at 15:58
I believe that the discrepancy you are seeing is caused by the two figures using different figures for capacity. This is just an educated guess but it looks as though the work details tab is using capacity at the start of the day, while the chart is using capacity at the end of the day.
If I'm correct, you can interpret the figures as follows.
From the chart: At the end of today there will be a little over 100h of capacity remaining. Right now there is somewhere between 120-130h of work to be done.
From the table: At the beginning of today there were 128h of work remaining in the sprint. At the beginning of today there were 130.5 man-hours available to do work.
either way there isn't a whole lot of slack...
While looking at the graph I noticed that the sprint lasts longer than you have capacity available. Are the values for sprint length and capacity set correctly?
