At present, the Sprint Burndown shows the actual progress relative to the ideal burndown. However, this does not reflect whether there is cause for alarm. If the Sprint Capacity is displayed (represented as a line that also burns down over the course of the Sprint), any roadblocks causing the burndown to exceed the remaining Capacity would be clearly evident, making it easier to detect when evasive action is required.

Comments

  • This is a very good idea. We had this sort of functionality with an Excel spreadsheet that we were using for Sprint tracking, before we moved to VersionOne, and this is a feature that I would really like to see in V1. As a Scrum Master or developer, the relationship between "To Do" and "Capacity" is crucial.

    Ideally, this would be combined with the ability to set each team member's daily capacity for the sprint. This would allow you to show when a team member is on vacation, or when there's a holiday. The capcity burndown would stay flat over those days, and the fact that the "To Do" doens't go down over those days would be expected. Our Excel spreadsheet allowed this functionality as well.

  • This is a great idea. I would like to see this funtionality added too.

    Sandi

  • I have also seen products that offer a burndown predictor line based on remaining team capacity from TODAY forward, as well as on the teams velocity over the previous 3 or 5 day average. This makes the burndown much more valuable to the team and would put you more in line with the functionality offered by some of your competitors.

  • I have also seen other software that provides both a predictive burndown line based on capacity over the time remaining as well as a predictive burndown based on the previous 3 or 5 days of the teams velocity. Both of these measures provide a much better view for the team.

  • I agree, this would be an excellent enhancement.

  • Our Project Manager is DYING to see this. We have been doing this manually, with the help of a spreadsheet, where we calculate based on the remaining ToDo hours and that user's daily capacity, factoring in any vacation days, when they should ideally be able to be done. Based on that, we go to the Member Burndown, and customize the parameters based on what is in the spreadsheet.

    What we SHOULD be able to do is enter the expected daily velocity for a team member, plus the number of vacation days left before the end of the sprint for that person. From this, that individual's capacity is auto-calculated. Then, in Sprint Planning, we enter in any team holidays, so that capacity calculations automatically adjust to accommodate them.

    With that, a true capacity burndown would be possible. And it would be a HUGE BOON to managers.

  • This is a great idea! I love it.

  • As a VersionOne Scrum Master I would like the sprint burndown chart to include a third line related to team hours available for the sprint so that I can compare progress against the team's capacity, rather than the ideal line. Team capacity may or may not match the total number of committed hours in the sprint, and so the burndown chart may not give a totally accurate picture of where we are, relative to "done." Our burndown charts before VersionOne included this line.

  • Add us to the list of people that are doing this manually - checking to see if there are sufficient hours left to accomplish as well as individual hours left to accomplish. This is something V1 should be able to analyze and report on very easily!

  • A must have in terms of effective sprint planning and monitoring. We use the Ultimate edition and advanced reporting. Even there it is almost impossible to compare capacity with plan and actual time tracking. This needs to be easily available somewhere in the product. This idea should be put into the product as soon as possible.

  • This IS a good idea but I suspect that you would not be able to actually do this until you fix member capacity. Capacity only works for iteration-based (read:scrum) teams at this point and there is no way to input capacity for kanban or non-iteration-based members. I'm voting it up but there is a larger issue at hand here that needs correction.

    I'd propose that there be meta-data on each member that allows true capacity per member, this would likely be needed to be further subdivided by portfolio item or planning level, or other divisions that members might work across.