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?
Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.Sign up to join this community
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:
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.
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.
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...