Estimatation …

This post was originally published on my last blog: Spike the Poodle

Imagine you and I were looking up at two skyscrapers, and I asked you how high you thought one of them was. You'd probably find it pretty hard to tell whether it was 50m or 500m. But what if I asked you how high the second one was in relation to the first? I bet you'd be able to say it was about a third larger, for example. If you could measure the height of the first building, it'd be much easier then to estimate the height of the second.

People are generally better at estimating relative size than absolute – and this doesn't just apply to buildings. In software development, estimating relative size – usually with story points – and then measuring how many points we can deliver in a given time is generally more accurate than trying to figure out how long a task will take in days, and then allowing for the general daily faffing.

Most developers have spent their careers estimating in time though, and making the transition to story points isn't always easy. There are a few things I've seen recently that can help people get comfortable more quickly with story points.

1. Estimate in a group with developers who have experience with story points.

Having developers in the group who have done it before is probably the best way to get the developers new to story points up and running quickly. They can set a good example and reassure the others that the technique does work. In an inexperienced group, doubt can plague the group and undermine the estimates.

2. You don't have to estimate QA and Dev effort together.

Some agile teams try to estimate the effort to complete a story to include all of the dev and QA work, but this is really, really hard. QA and development are very different skillsets, and it can be frustrating for the team members to have to estimate something they can't be expected to understand.

For teams practicing test driven development and writing unit tests, QA involvement can happen at the start and end of story development, with the QA and BA working together to write acceptance tests prior to development and sign off the story when development is complete. Unless the QA effort is really significant, it's probably OK to represent the dev effort in story points, and have the QAs check the estimates, and just highlight any that are unusually low but might cause a bottle neck for them.

3. Agree a good scale.

There are two common scales for story points: the fibonacci sequence and the power of two, and both work well. The important thing is to agree a sequence in advance, and ensure the upper bound isn't too high. Either 1, 2, 3, 5, 8 or 1, 2, 4, 8 works well. You might choose to use 0 and 0.5 for really small things like configuration. 13 or 16 point estimates become less meaningful and far less accurate – can you really think in terms of 13 times the size of a 1 point story?

Give developers a question mark for the stories they can't estimate – these are the ones that are too big, or have too many open questions. They'll need more analysis or splitting before you can estimate.

4. Get good story granularity.

Whatever estimation scale your developers agree, your stories will need to be small enough to fit into it. Usually your largest stories should be no more than eight times as big as the smallest ones, and you'll need to be clear about what each of them really means.

The best way to judge the granularity is to have some of the more experienced developers review them before you start estimating. This doesn't have to take very long. On a recent project, we spent maybe three or four sessions with developers prior to estimation, each one about an hour long. It might sound a lot, but it's worth it – there were only two stories out of nearly 700 that they couldn't estimate.

5. Capture Low, Likely and High estimates.

In some versions of planning poker, you're supposed to aim for convergence between the team members on an estimate. You can do two or three rounds of estimates on a single story to try and get there. The trouble is that this can take a long time, and get frustrating if team members don't want to budge.

One way of getting around this is to capture low, medium and high estimates, taking the lowest, highest and middle ground from the estimates from all of the developers. They may not agree, that's OK, and it's also OK to capture the disagreement and move on.

The low and high values can be used to weight estimates for release planning.

6. Get comfortable with assumptions.

Stories are a promise for a conversation. You won't know all the details of the requirement when you estimate, it's agile, you're not supposed to. In some cases, you might have a better idea in your head than what's written down on the card.

It's OK to make an estimate based on assumptions (make sure you record the assumptions with the story though!) Assumptions can help move the estimation along faster. If it turns out the assumption was wrong, then the estimate is also wrong and can be redone later.

7. Be prepared for estimation to take a long time – especially at the start!

In a recent estimation session I attended, the first estimate took well over ten minutes of discussion to arrive at. Some people were looking at the list of stories and starting to sweat and wonder if we'd ever make it through to the end!

This is normal, especially in a newly formed team, they will take time to speed up, but they will get there. Don't try and finish estimation in an hour, it's not going to happen unless you've got a week long project. The team need an adequate amount of time to not feel stressed and get used to estimates, it will pay off when you're able to speed through fifty stories in an hour and get an accurate release plan later on.

8. Calibrate several stories in advance with a smaller group.

Calibration is the process by which you arrive at the initial size of a story point. It's time consuming and challenging – we took an hour or so to calibrate four stories. If you're working with a mixed team of developers who are both experienced with and new to story points, it's worth taking the time with those who are more comfortable with story points to do the calibration first.

It's key to pick the right stories for calibration. Whatever scale you choose, find a story that fits each bracket – you may have to go through several to get there. When you're done, pin them up on the wall and refer back to them for the first few rounds of estimation: "Is this the same as that 3 point story on the wall?"

9. Use ideal days in the initial calibration.

To start calibration, use a scale like 1 ideal day = 1 story point – but only use it for the initial calibration! Once you have your scale, don't refer back to ideal days as it will muddy the waters – it's OK to use to get going, but after that try to just size against the other stories and forget about duration.

10. Triangulate with a sample of stories.

Triangulation, or cross checking the consistency your estimates, can happen at any point during or even after estimation.

You don't have to check every single story if you have a lot. One technique is to sample 5-10 from the middle estimates (e.g. 1, 3 and 5) and compare them. If they're reasonably consistent within and across the estimates (i.e. a 3 is about three times a 1) there's no need to compare any more.

A quick conclusion …

Like many aspects of agile, estimating with story points is not easy, but it is effective. I plan to write soon about going on to use the estimates for release planning, so stay tuned!