Redesign task hour interpretation
When pulling a story with an estimated work load to a sprint, the estimate of this story is not considered in the burn down chart. Instead, the burn down chart remains at constant 0, until tasks are created. In the end, the correctness of the initial estimate is not visible in the burn down chart, because it is based purely on tasks.
Here's my suggestion:
Like the field for assumed velocity, add a field for the assumed "story points to hours" ratio. Use this ratio, to include all of the sprints stories time estimates in the burn down chart. When creating new tasks, the chart should not change, as long as the total amount of task hours does not reach the stories time estimate. Only when more tasks are added to the story, so that the sum of time of all the stories tasks becomes greater than the stories estimate, the chart should be corrected upwards. Additionally, when the product owner accepts a finished story, and the total amount of hours logged in its task is lower than the stories estimate, only then should the chart be corrected straight downwards. This way, all vertical bumps in the burn down chart would correspond to either belatedly added stories, which the team members know of, or would actually show errors in the time estimates.
This would greatly improve the usefulness of kunagi's burn down chart, and would remove the jittery jumps and drops caused by the late addition of tasks, or caused by tasks, that are simply added to not be forgotten, but do not have a sufficient work load to justify an estimate of one hour. Currently, these tasks cause a vertical up bump when added to the story with 1 hour estimated, and cause a second vertical drop a few days later when they have been resolved after 5 minutes of work, which would be logged as 0 hours burned, reducing the stories total amount of time to the previous value. To further improve this, it would be nice to see the option of adding tasks with an estimate of 0 hours, but still not closed: Allowing 0 hour estimated tasks would enable users to note small "todo notes" within kunagi's task system, without screwing the burn down chart and other related time estimates.
Statement from Kunagi Team
The suggestion mixes up concepts that are not directly related (see comments). Part of issue was extracted to iss389.
Status
Issue is closed.
Comments
Thu, Jan 13, 2011, 16:38 by Witek (SM,T)
I understand, we have a problem with small tasks (5min). We have to find a solution there.
But I do not agree on the ignoring of task estimations. If the Team estimates more StoryPoints then it creates tasks, the Team should learn from this for the next estimation of Stories, instead of faking the burndown chart.
Perhaps vertical jumps are ugly, but if they reflect the truth about the current estimation of the remaining work, they have to be there.
Solving the problem with small tasks should also reduce the jumps. What do you think of estimating tasks in hours:minutes?
Thu, Jan 13, 2011, 21:26 by artjom (PO,T)
One quick note on your interpretation of "work load": Estimation is Story Points is not an estimation of work load. It is an estimation of overall requirement complexity. It is different from the actual work load (e. g. in hours).
The Sprint Burndown, however, shows the burndown of actual estimated work (as in Tasks that need to be done to fulfill a requirement). Consequently, when there are no Tasks, it is not reflected in the Burndown.
Now to the actual problem: It is indeed correct that we do not support very short Tasks. We should concider that. It is, however, not the Tools fault if your Burndown chart jumps a lot. It is much rather an indication of the Team not doing high quality estimation (yet). The literature reports this to be not uncommon in fresh Scrum Teams. Your estimations will get better in the future and will manifest in a smoother burndown. As a matter of fact, it was possible to see the same phenomenon in our own burndowns.
I have created iss389 to deal with very short Tasks. As for the rest of this issue, I concider it closed due to the reasons explained above.