We have decided not to include more metrics into Kunagi, because it remains unclear for what purpose they should serve to give feedback about the project's performance.

Especially, the central performance metric in Scrum is the Sprint Burndown Chart. Displaying additional metrics bears the danger of compromising that fact, because it distracts from the one important chart.

Let us look at the metrics you propose to see what I mean:

1. Tasks that are spawn and late re-estimation that adds or substracts work can be easily seen in the burndown chart, because it is displayed as vertical bumps. A separate metric would give you a nimeric value, but what would it be good for? An optimal result would be to not have such bumps, and suboptimal is having many. It doesn't really matter whether it's, say, 20 hours or 23.
2. You can see a visualisation of the Story burndown in the Whiteboard view. The more of the Tasks have been dragged to the right, the more ingredients to it (Tasks) have been completed. This should lead to the Tasks drifting to the right in the Whiteboard. It might be argued that Tasks (as a discrete object that might have several possible estimations) do not necessarily represent the relative amount of buned work, it is good practice, however, to keep Tasks small and of approximately equal complexity.
3. Comparing estimation vs. burned hours does not necessarily make sense at all (depending on what you mean, exactly). The values in the Story's estimation (Story Points) and the work estimation of Tasks (hours) does not correspond. It is therefore impossible to compare them. It would be possible to compare initial Task estimation to the work that had to be done in the end, but again, for such small entities as Tasks this is rather tedious. What knowledge would you win by knowing exact measures for your mis-estimation. In the end, it comes down to the quality of the Sprint Burndown again.

There are two more, rather technical reason, for not implementing more statistics. Firsly, additional statistics would have to be displayed somewhere. The UI is already pretty complex, so it would be not a good idea to put it into the Whiteboard or Sprint Backlog views (especially, because it distracts, as I argued above). So it would have to be some specific Statistics view. Adding additional views is always a semi-elegant solution. Secondly, we would have to maintain the view and the underlying code. Given it's limited usefulness, we believe, it would be more work than gain.

Thanks for your fast and comprehensible reply.

Let me try to explain a use-case:
- The team estimates a story, e.g. 2 story points
- The team creates tasks for e.g. 20h for that story (this should display some kind of warning/notice)
- During the sprint the team notices that there is some more work to do and adds some more tasks, or the product owner wants to have more features for that story...
- At the end of the sprint the story took e.g. 4 story points so the estimation was pretty useless.
At the moment there is not easy way to find out that this mis-estimation was the reason why other stories remained untouched. It would be very handy to have such an overview.

There could be many more charts displayed at the position of the burndown chart - just add some buttons to switch the charts. As the burndown chart of the current sprint is the most important chart it could be displayed per default if you open the whiteboard (so there is no need to store the chart which the user has selected).

Well, there is no doubt that more statistics could be displayed, but the one actual advantage over not having them is, in my opinion, that people like fancy statistics. I doubt that this is of any use, though. There was an article about that some time ago in the Hardward Business Review, but unfortunately I cannot find it now.

As for the use case you describe, I beg to disagree that it could be done this way. Note that Story Points (SP) are a measure of general complexity, not time. There might be several aspects that influence the actual time needed to implement a Story.

The simplest one is skill of the person who does it. While Scrum encourages (or even demands) Teams to be independent, it follows that different skills need to be represented (e.g. development, testing, artwork, ...). Also, there is always a discrepancy in skill even within one group of Team Members. There is a huge difference in effort needed depending on whether the guy on an implementation Task is a senior developer or a junior tester. It is, however, neither bad nor disencouraged to have people interchange their field of work.

You could try to use the hours to determine the quality of your initial SP estimation of the Story, but this clearly cannot be done if the number of hours burned is higher or lower than average due to such external influence.

Especially, this does not change the general complexity of the Story that is measured relative to other Stories, not in terms of actual work needed to accomplish the goal.

@torfo: I think your error ist to think of StoryPotints as a measure for concrete time (like days or hours). It is not. A Story with 2SP could be completed by a professional in 2 hours, while a newbie would need 20 hours. That way the two would never be able to agree on a value for estimation. Therefore Scrum uses Story Points as an abstract measure. Everybody can agree that Story A needs twice the time then Story B. Beginnes often see StoryPoints as workdays or hours, but this is a bad idea in Scrum.

After the sprint is over, you can see how mich Story Points the Team needed. Which gives a hint, how much to pull into the next sprint. The hours from burned tasks are not relevant. These are only required for tracking the progress within the sprint.

• blog.mountaingoatsoftware.com/..ts-relate-to-hours
• scrummethodology.com/..estimation-and-story-points
• scrum-breakfast.com/..ry-points-to-management.html