Storypoints added up in a burndown chart?
Hello,
I have a question regarding storypoints.
One advantage of storypoints over hours is that is abstract in stead of absolute.
So you can assign for example 1 or 5 abstract storypoints to a story.
In the burndown chart all these storypoints for all the stories in the sprint are added up however..
This does not make sense to me however.:
1) adding up is a very absolute operation, so this cannot and should not be done on abstract items..
2) 1 + 5 results in a total of 6 storypoints on the burndown chart, which implictly makes them absolute. Now all of a sudden 1 storypoint is exactly 5 times smaller then 5 storypoints..
this relationship is made even more absolute by plotting it linear against time..
So it looks to me that If you want to use the burndown chart, then storypoints cannot be considered abstract therefor during pokering, or if you want to use abstract storypoints then you cannot use a burndown chart.
Isn't it very weird to use storypoints as abstract during pokering and treat them as absolute all of a sudden on your burndown chart?
Story points are abstract but they only having meaning relative to the estimates against other stories.
On average, a 1 point story should be approximately 5 times less complex than a 5 point story.
Plotting against time is useful as the Sprint itself is timeboxed, so burndown charts can be a good tool for a development team to gauge how close they are to delivering all of the planned work.
While the individual story points have no direct time value, the amount of points a team can deliver within the Sprint (their velocity) can be used for forecasting.
The Sprint Retrospective is a good time for teams to review the work delivered and consider whether their estimates were accurate. Whether they were or not will good knowledge to feed into the next estimation session.
I like the idea of team's having reference stories too, e.g. a really good example of what a "five pointer" looks like to us. Then during estimation your first thoughts can be "is this story more or less complex than that reference story?".
The purpose of estimation is to help a team get its arms around how much work it reckons it can take on. To that extent, estimation must be concrete irrespective of the method used.
A team may reckon it has a Sprint capacity of 40 points for example. Hopefully that estimate will be reasonably concrete in so far as it is grounded in real-world data, and does not come out of thin air.
To determine how much work remains in a Sprint, all we care about is that constituent items are relatively sized.