In my last post I mentioned a common controversy linked with story points. Common wisdom asserts that they shouldn’t be used to represent time, but this is on over-simplification which inhibits good estimation.
A key question I like to ask Scrum teams from time to time, is: “What is a story point?”. The first time I ask this of a team I’ll normally get one of the following two answers:
- Story points are a measure of complexity
- X points = 1 day of work
The first answer is much too vague. For a new developer on the team, John, it tells him nothing he needs to know. Even if he knows what story points are, how can he possibly estimate a story from this definition? Does he guess for his first few and hope to calibrate after getting a few times? As a team we risk losing out on potentially valuable insight from him for these first few as we’ll naturally discount them as inaccurate. Finally, how do you even measure ‘complexity’?
The second answer also has problems though; let’s call our hotshot developer on the team Carol, and our intern is Tim. They are estimating a story and they have the following argument:
Carol: I can do that in an hour, so it’s 1 point.
Tim: It’ll take me at least a day, so it’s 8 points minimum.
There’s no way to break the deadlock here, as they are both right. Carol may easily be able to finish something in an hour that’d take Tim a day or more. What’s worse, we’ll have the same problem with anything we try and estimate if these two are on a team!
We’re missing the same thing from both answers: a good benchmark. We’re trying to measure things without a ruler. Let’s modify and combine our definitions so that we have the following:
Story points measure time, where we define [feature X] to be 5 points.
With a benchmark story laid out, we’re in a much better place. Carol reasons that as [feature X] would take her 3 hours, then this new task which will take an hour is 2 points. Tim thinks [feature X] is a good couple of days work though, so this new feature is half that, or about 2/3 points. Tim and Carol then discuss and agree to settle on 2 points. The deadlock is broken and any future disagreement should encourage useful discussion, on what a feature represents, rather than getting caught up on the differing rates people work.
John also has a much easier time getting up to speed. If [feature X] is something well understood like to create a login page for our website, he can build a fairly good picture of what 5 points looks like to help him estimate right away. He can immediately and confidently contribute to estimations and related discussions.
I quietly sidelined the concept of ‘complexity’ earlier, but it’s worth revisiting. Complexity is a very tough thing to measure – something that is complex isn’t necessarily going to take a long time to do (doing a cartwheel) and conversely, something simple might take a long time (sleeping for 8 hours). It’s for this reason I don’t like to explicitly measure things in terms of complexity alone. I do recommend that teams factor complexity into their estimates though – if something is unusually complex I’d expect estimates on it to be higher than normal.
Complexity isn’t the only such factor that can influence an estimate though, and as a Scrum Master it’s not my job to police whether an estimate is ‘right’. Instead I like to keep an eye on the sorts of questions the team are asking as my guide for whether they are taking everything into account. Useful questions the team should be asking are the ones like the following:
- How many other systems are impacted by this change?
- Have we done this before?
- How many different members of the team need to be involved in this?
- Do we have all the information we need to get started?
- How long ago did we last change this bit of the code?
- What is the likelihood that the customer will have feedback on this that requires us to change our implementation once it’s in progress?
- Can we write an automated test for this?
It all comes back to the key point from my last piece. The main purpose of estimating stories is to open a dialogue around features early, which fosters an environment of collaboration and equality. It is this cultural shift, that is at the heart of Agile, which so many teams miss out on focussing instead on getting ‘the right number’. This culture of conversation is far more valuable than the estimate we assign a story.
About the Author
Scrum Master at Made Tech
Coffee and cookie fuelled Agile evangelist.
