Friday, October 5, 2012

Scrum and Story Points, what's the story?

After working with scrum for a while and watching this debate of time vs story points I came to a personal conclusion that helped me to make better estimations and use the story points at their best value.

  In my opinion story points best measure risk. You estimate this risk taking into account your proficiency, overall experience and the expertise in the technology, the project and it's business, the dependencies involved that you need to rely on to move forward (could be external systems/teams, business analysts, other people availability) and your average capacity of solving problems in a given time.

  So when it comes to estimating a user story you should ask yourself: “what is the risk of this story?” I would categorize the risk vs story points as follows:

1 point - Virtually no risk, insignificant work doable in a very short time

3 points - Extremely low risk, know all about it can do it quickly, probably a matter of 1-2 hours

5 points - Low risk, know most about what I need to do, probably can fit in few hours to one working day

8 points - Medium risk, know quite well about what I need to do, I might have some unexpected obstacles and maybe some dependencies on other (external) resources, but I am confident I can do it in 1-3 days.

13 points - High risk, there are aspects about I have no idea on how to tackle, have external dependencies about that I am worried, it might take half of a sprint to get it done.

21 points - Highest risk, I have right now no knowledge about the subject and no idea of how to do it, there are lots of dependencies on other (external) resources that I cannot manage, I am not sure I can solve it in a sprint so that story becomes demoable. Then you should ask yourself: is this really a good story or rather an epic? Shouldn't  it better go into a research spike first so that we gather more knowledge about how to do it?

However, when you estimate always take into consideration collateral aspects such as unit/functional/integration test writing (that can take as much or more than time need to code functionality), team communication, code reviews and other things that should be part of your development process.

What do you think?

Cheers,
Dikran.

No comments :

Post a Comment