A couple of days ago I found myself describing how to estimate the size of a story. It was coming out in my own words, without references. It felt... right.
One agile approach for "sizing" up a task is to use a relative scale to describe a mixture of effort, complexity and uncertainty.
1 pt - Oh I know what that it is, and exactly how to do it.
2 pts - Oh that's about twice as hard as a 1.
3 pts - Twice as much effort again.
5 pts - Hmmm, there's some tricky bits in there I'm not sure about, but I know someone who knows, and can get help.
8 pts - A few unknowns in there. I can't be confident about what's involved.
13 pts - Need more information before I can begin to estimate what's involved.
21 pts - Epic. No way we could do that in one sprint. We need to break this down into smaller pieces, but we can do that later if it's not a priority.
Swap out unknowns for complexity. If a task is understood but complex, the chance of error is higher, as is the need for greater review and testing. Build that in when estimating. Don't devalue review and quality assurance, they are critical steps to agile success.
It also makes sense to add points to stories known to be simple but incredibly time-intensive. A simple, but tedious and repetitive task introduces risk because the person doing it may get tired, bored or hungry. Tired, bored, hungry human beings don't produce their best work. Again, you will need to factor in additional time for review and testing by someone with fresh eyes, or break that task down into smaller steps.
It's way too easy to get caught up matching Story Points to time, especially when doing quotes or reconciling budgets. Story Points are best for helping a team and their product owner to focus on what can be achieved now, in this sprint. Keeping it real.
What do you think?
Image: Shamelessly "borrowed" from http://www.powerhouse360.com/2012/03/story-points/ <= also a good post on this topic!
- Log in to post comments