Email iconarrow-down-circleGroup 8Path 3arrow-rightGroup 4Combined Shapearrow-rightGroup 4Combined ShapeUntitled 2Untitled 2Path 3ozFill 166crosscupcake-icondribbble iconGroupPage 1GitHamburgerPage 1Page 1LinkedInOval 1Page 1Email iconphone iconPodcast ctaPodcast ctaPodcastpushpinblog icon copy 2 + Bitmap Copy 2Fill 1medal copy 3Group 7twitter icontwitter iconPage 1

Ask a developer to tell you how long something is going to take to develop and be prepared for one of several responses, none of which are particularly useful for planning a project:

  • A genuine attempt to estimate which ultimately turns to be inaccurate by anything between a factor of 2-5
  • A sarcastic response telling you ‘it will take as long as it will take’
  • A guesstimate with the caveat that you should multiply the estimate by 3 just in case

Even so, asking individual developers or line managers to estimate their part of a project in units of time is still the most common way of estimating. Deep down you know it just doesn’t work, rather it leaves everyone from the developer through to the product owner with a sense of dissatisfaction that they didn’t get it right. Everyone promises that next time they will account for all the ‘troublesome’ things that got in their way and convince themselves their next estimates will be accurate. But guess what? The next time round the estimates are no more accurate and this time a new set of ‘troublesome’ things have got in the way. And so it continues, over and over because it’s just not possible to ask one person – no matter how skilled – to solve ‘the riddle, wrapped in a mystery, inside an enigma’ that is accurate software development estimations.

And why is that? Well, there are many reasons, in fact the sheer number of reasons why estimates can go badly wrong when estimating technically challenging problems accounts for poor estimations in itself but I personally like a quote from Dan Milstein’s blog post which sums it up nicely:

Writing Software = Learning Something You Don’t Know When You Start

I’ve failed many times trying to estimate things in time, both as a developer, then as a project manager but yet it was only when we started tracking time with Harvest I was able to see just how inaccurate – and utterly futile – estimating this way was. I mean, part of me always knew it was wrong but knowing just how wrong was an eye opener, and actually a game changer for UVd. We had to find a better way of doing things.

Attempt the possible not the impossible

It seems to me that people keep trying to do the impossible over and over, expecting different results each time they do it (and we all know what Einstein had to say on such matters). So why bother? Why not just focus on doing the few things we know we can do instead? And here are a few things I know:

Relatively sizing is possible: If I gave a developer 2 well defined user stories and asked them to use their gut instinct to tell me which is the more complex, they would have a very good chance of getting it right. And so we already have more useful information than if I asked them to analyse them in detail to estimate them in time (which for the above reasons is often futile). And this relative sizing takes a fraction of the time.

Two (or ideally more) heads better than one: Taking the technique above to another level we can involve more people from the production team to discuss the story and to join in the sizing activity. People tend to focus on different aspects of the user story through design, build or frontend aspects. This approach ultimately increases exposure to hidden complexity or might even result in a simpler alternative way of doing something.

The customer is always right (unless you can convince them otherwise): If you find yourself arguing with your client about something that you’ve delivered that they think is wrong or not quite what they were looking for then you only have yourself to blame. Your customers will always have their own interpretation of how something should work. It might not always be the correct solution but it’s theirs and it’s embedded in their head, so unless you have buy in for an alternative (and better because that’s what you’re paid for) solution you’re going to fight this battle over and over again. Instead, harness what your customer has to offer, engage them in the discussions with everyone about the user story; ask them to read out the user story and describe what it means to them and then allow everyone to ask them questions. What we know, is that by doing this you’re eliminating one more uncertainty.

Don’t try to be too clever, clever will outsmart you: Planning poker can be done in several ways but I’m in favour of simplicity in terms of sizing options. Commonly, something like the Fibonacci sequence is used for points scoring but I find this a little confusing for the team and product owner to understand, and also in my opinion is a little too granular in it’s sizing (it’s hard to comprehend the difference between 55 and 89). We use a slightly less common (but often practiced) set of sizing called t-shirt sizing. Our job is to size stories into 3 piles – small, medium and large). Keeping it simple reduces the chances of error.

Precursors to estimating

Estimating requires decent user stories. Following the INVEST model you can achieve this:

  • “I” ndependent (of all others)
  • “N” egotiable (not a specific contract for features)
  • “V” aluable (or vertical)
  • “E” stimable (to a good approximation)
  • “S” mall (so as to fit within an iteration)
  • T” estable (in principle, even if there isn’t a test for it yet)

I’ve also written previously about user story refinement which is a rough process for allowing ourselves to refine user stories to the point that they can be worked on.

Planning Poker

We run planning poker sessions when a product backlog is first created. You don’t necessarily need to run the session against the entire product backlog if you have a lot of user stories because you could take a cross section of them (say 20%) and extrapolate the entire backlog from the results.

You’ll also want to run new sessions as you progress through development and the backlog is further refined and added to (as will always happen). It’s best to defer sizing as with development as long as possible so that when it comes to it you know as much as you possibly can. On our latest project for thomsonlocal we’ve run one session on the user stories within the first 2 high priority EPICS and will then run fortnightly sessions after that (and as we run 1 week sprints it means we are always one cycle ahead with the planning as we are with the development).

The more the merrier (within reason)

We’re a fairly small cross-functional team so I like to involve as many of the team members within the session as possible. A good cross-section of functions is necessary to get a balanced view of the stories we’re sizing because in our case, there may be some that require very little backend but are quite complex on the fronted development. Most importantly, make sure you include the product owner (or most appropriate stakeholder from your client team).

Prepare the session

Bring the team together, in our case this might be 2 or 3 backend developers, 1 or 2 fronted developers, a tester, a project manager, a designer (visual designer) AND the product owner. We like to congregate around our breakfast bar where we have our stand-ups because it means we can all stand in a circle which maintains good dynamics and communication.

  • Supply the product owner with printouts of the backlog you’re going to size.
  • Supply each team member (excluding the product owner) with their sizing cards. In our case this is only 3 cards each (S, M, L) but others choose to use the Fibonacci sequence for points.
Let the the session begin

User story Q&A: Allow the product owner to read out the story, any relevant notes on the card and acceptance criteria if you have them. Then allow the product owner to field a Q&A from all participants.

Time to play your cards: When all questions have been fielded it’s time for the team members to reveal their hand (at the same time so there is no external influence). Each member reveals one of 3 cards – small, medium or large. There’s an element of gut instinct that has to be used at this stage. It’s impossible to know everything and as the user story should be (N)egotiable and isn’t a specification document, it’s important to remember that there will always be variation in any potential solution. If everyone reveals the same card (unlikely) the size can be marked on the user story and the product owner moves onto the next.

Handle differences in opinion: In most cases we tend to find differences in opinion, so it’s necessary to focus on those who don’t agree on the general consensus. For instance, if 3 people put down medium, one put down small and the other large, its time to focus on the small and large. A 2 minute egg timer is used so as to keep conversation snappy (this is VERY important), within which the individual describes why they feel the sizing is different (perhaps they have a concern that others haven’t thought about or possibly an idea of how something could be done really easily because they’ve done it before). Once the egg timer has run out it’s time to vote again.

Continue the cycle until a consensus is met: The aim is to converge on a consensus of size but it’s entirely possible that an individual can reveal some information as to why a story might be larger or smaller than the majority think and for the majority to shift opinion entirely. I’ve seem teams switch from small to large and visa-versa. The point is that an open discussion with the team will facilitate greater shared knowledge and understanding. Concerns and opinions bubble to the surface way before any development is done which is a far more efficient way of handling them.

Handling sticky difference in opinion: In the case where we have a minority of outliers after several rounds and when it looks like we’re not going to get complete consensus then it’s up to the person running the session to ask if they are OK if we go with the majority. We then handle this by marking on the user story the variation and any notes about individual concerns which can then be re-visited when we come to implementation.

General advice

Make sure that people come to the session open minded and prepared to voice opinion (and listen to others). You’ll ideally need an environment where the introvert isn’t afraid to speak out and the extrovert is willing to shut up and listen! A dysfunctional team will always struggle to make the most of the session because in such a team some members aren’t willing to open up, and others strive to drive their opinion home. It just defeats the purpose of the session. It’s therefore a good idea to set some ground rules prior to commencing the session and to run through what’s expected of all participants. If you set the expectations clearly then it will be easier for individuals to understand what’s required of them and behave accordingly.

I hope you’ve found this useful and as always, this is my view of a process that works well for us but which we’re always learning from and adapting. Of course, it’s not the only way either and I’m always interested in how others handle planning and estimating software projects.

In my next post I’ll try to explain how we take these sized user stories and plan a project around the information we have gleaned from the session in order to be able to set project budgets and release strategy.


Why we no longer do Estimating

Agile Planning without Points

Improve your estimation accuracy with Planning Poker

Coding, Fast and Slow: Developers and the Psychology of Overconfidence