I stand corrected – TWO of our teams used to create task cards with the words ‘just do it’ written on them! :p

Anyway, I’m firmly of the belief that you estimate in Story Points and then task out and burn down in hours. I ran a session on this at London Scrum User Group and that seemed to be the consensus there as well. For me Story Points are more for the business and during the sprint the development team are the people looking at the burndown and this graph is for them, at the end of the sprint we deliver a number of Story Points to the business but they’re only interested in this after the sprint finishes, not during it.

That’s my 2c anyway!

Tom

It’s interesting you see it that way. I rather like the abstract nature of Story Points.

When we were estimating in hours, our Stakeholders/Product Owners/Senior Management often over-analysed the situation – the fact we were using a more precise measurement lead them to believe that we were being accurate!

The reality of the situation is we never actually booked a sprint at 100% capacity. In fact, I remember one occasion where a team of four entered into a two week sprint with 60 hours of work. This raised all sorts of questions…

e.g.

“why did Bob only work 20 hours last sprint?”
“but they’ve only committed to a fraction of their capacity?!”
“that team’s not working hard enough”

We no longer have these types of conversations.

Just a thought.

Tara

I would strongly recommend such approach because this way you can notice where your estimations are more guessing than really touching the true value (if the story point is very big it means that you have to break it into smaller ones).

Reestimating stories in hours usually comes down to estimating tasks that were identified for each story and as such they become at some point incomparable. So we loose the ability to use relative estimates as tasks fall into different types of activities. This way we need to think about hours required for each task individually and maybe comparing them to other tasks of the same type (like designing UI, writing javascript code, etc.) may help in estimating them.

I wrote about it some time ago in Are you brave enough not to estimate your tasks? which was followed by quite vibrant and interesting discussion at LinkedIn Agile Group

When burning down the whole stories it may be helpful to use some cumulative charts that show stories in different states during the iteration (PENDING, IN PROGRESS, COMPLETED, etc.). This way even if they actually burn down late in the iteration you will get a view on what’s going on with the flow during the iteration.

Regards,
Marcin