In Part 1, we talked about the primary problems with estimating software development accurately:
- Your task will have hidden complexity you hadn’t considered, as a function of it being software
- You will be given extra or unrelated work to do, and if you fail to track and communicate this, you will look lazy and incompetent
But we ended with the uplifting message, which is if you plan for the former (by multiplying out your estimates), and make sure you adequately track the latter, then your estimates – when taken in aggregate – will probably be ok. And by ok, I mean better than 90% of other developers.
But who wants to be a 10 percenter, when you can be a 1 percenter?
I also promised Agile was going to solve all your problems ever when it came to estimating. This may not have been 100% accurate. What we are going to do is look at a whole bunch of Good Ideas(TM) that the Agile folk stole, curated, and invented when it comes to estimation.
Humans are Weird About Time
It turns out that we humans get a little weird about time. However much you believe “six hours” is “just an estimate”, however much buy-in there is from the team about this, and however many times you’ve accepted that there’s always hidden complexity, if a six hour task takes eighteen hours, everyone gets a little squirrely.
Squirrely is bad, because squirrely is bad for morale, and squirrely is bad for Project Manager / Developer relations. Squirrely leads to developers trying to hide actual progress and injecting “slush fund” tickets in to the work list (Agile: Backlog) that they can use to burn time down against, and leads to them getting demotivated, which leads to them spending more time on Reddit, and it’s a vicious cycle.
The first rule of Agile Estimation Club is that we estimate in Story Points, not time, and the second rule of Agile Estimation Club is that no-one ever tries to work out the Story Point to hour conversion rate (a Story is a collection of tasks, or one big task).
Good Idea #1: Stop estimating in time, because everyone has deeply held beliefs about time.
Story Points
Story Points are a measurement of the complexity and tedium associated with a task. Complexity is important, because complexity hides other complexity, and tedium is important because no-one works effectively on boring tasks.
How do we measure Story Points? Simple. Story Points are measured in Story Points.
What this really means is we estimate tasks in relation to each other. Is this task about the same complexity and tediosity as that task? If so, you should give it the same number of Story Points.
It’s super-tempting when you get started to estimate things in ‘days’ or ‘hours’, and then just drop the units, and look, you have Story Points! Don’t do this: everyone will remember that 8 points is ‘really’ 8 days, and people will get squirrely. The whole point with Story Points is breaking the relationship – at an individual task level – between Story Points and chronological time.
Good Idea #2: Estimate the complexity and tedium of tasks in relation to each other, rather than in relation to time.
A Couple of Refinements
Many teams estimate using numbers from the Fibonacci Sequence. That is, you’re only allowed to estimate your tickets using one of:
1, 2, 3, 5, 8, 13, 21, 34, 55
Although, This Is Agile, and so you’ll get cretinous Agile Consultants telling you how you only estimate using the Fibonacci Sequence, and then hand out cards with ‘1, 3, 8, 20, 40, 100’ on them, because they’re nice round numbers *twitch* – actually this doesn’t matter, as we’ll see, but still…
The idea here is that is a task’s complexity-tedium index grows, you have to decrease the accuracy – that is: the more complex a task is, the less chance you have of accurately estimating it, and you should account for that. When torn between two numbers, go for the larger – you’ll usually be right.
Good Idea #3: The more complex and tedious a task, the less accurate your estimates will be.
Velocity
If there was no relationship at all between Story Points and time, then there wouldn’t be much point in estimating.
We talked a lot about why we estimate previously, and estimates in complexity and tedium are of no interest to the business as a whole. The business needs Gantt charts, it needs deadlines, and it needs the occasional project to go massively over-budget and over-time so that one-day Presidential hopefuls can swoop in and fix them.
Velocity describes the number of Story Points a team can deliver in an iteration, which is a fixed period of time (three weeks, for example). In mature teams, Velocity should be fairly stable, and should see gradual increases as a team removes impediments.
When you’ve estimated every task or Story in your task list (ie: you’ve thought about and estimated everything you need to do), and once you know your Velocity, then you can tell the business how long something is going to take. You know you get 100 points done every 3 weeks, there are 1,200 points, and it’s maths that even an Agile Consultant can do… What’s more, for the first time, the estimates are likely to be somewhat accurate.
Good Idea #4: Your estimates relate to time only in aggregate, and only based on previous experience.
Mixed Ability Teams
Development teams are rarely homogenous. Some developers are worth three other developers, and some are regularly commiting work that needs to be unpicked and undone by other developers. Some developers have an OCD-level attention to detail, and some a stalkerish devotion to Twitter.
This has potential to screw time-based estimation systems. Remember: people get squirrely when something quantified in chronological units doesn’t match up to elapsed time. If a Senior Dev estimated a ticket as three hours, and a Junior is about to start their tenth hour on it, that’s going to be demoralizing. And if a Senior Dev is about to complete their third ten hour task in under an hour, they may get to thinking it’s time to see what’s new from Horse Ebooks.
When you estimate Stories in terms of each other, this largely goes away – people stop estimating Stories based on how long they think it will take them to do, and instead base them on how relatively difficult they are. This is a fundamental win, which I’m struggling to adequately do justice to here.
Good Idea #5: Estimating stories in Story Points and using Velocity for estimtes accounts for mixed-ability teams. This is huge.
Planning Poker
This brings us neatly to our final point, which is to do with the actual estimation process itself. I have the attention of a gnat when I’m not talking, which makes meetings at which I can’t be talking most of the time a nightmare for me (and ones when I can a nightmare for other people). Estimating meetings fit this category, as estimating is meant to be collaborative.
Everyone in the team should get their say when it comes to estimating, especially as they may end up doing the Story or task at hand. What usually happens, though, is that one person dominates, lays down their opinion, and everyone else plays Angry Birds on their phone. This is probably a bad thing.
The process of Planning Poker is: everyone has a deck of cards with the Fibonacci sequence (or some pretty, incrementing numbers labelled as the Fibonacci sequence *twitch*) on them. Each Story is discussed, and then everyone lays a card, face down, on the table with their estimate. Once everyone has selected a card, everyone turns them over at once.
You ask the person with the highest card why they think it’s such a complex task, and the person with the lowest card why they think it’s relatively simple. Anyone else can air their views too. Rinse and repeat until a consensus is reached.
This makes it very difficult to play Angry Birds.
If the team has been discussing what actual work a Story entails, and you haven’t been paying attention, you’ll struggle to put a sensible estimation down, and then you’ll be asked for why you chose such an estimate. If you guessed, rather than estimated, you may struggle with this, and your Project Manager will start to notice. With a persuasive (or sadistic) enough Project Manager, this leads to everyone being engaged.
Good Idea #6: Build shared ownership and engagement in the estimation process by estimating independently, then discussing collaboratively.
Summary
We’ve covered six good ideas from the Agile Estimation Process:
- Stop estimating in time, because everyone has deeply held beliefs about time
- Estimate the complexity and tedium of tasks in relation to each other, rather than in relation to time
- The more complex and tedious a task, the less accurate your estimates will be
- Your estimates relate to time only in aggregate, and only based on previous experience
- Estimating stories in Story Points and using Velocity for estimates accounts for mixed-ability teams. This is huge
- Build shared ownership and engagement in the estimation process by estimating independently, then discussing collaboratively
We haven’t covered all the intricacies of how to get started though. I suggest you start by Googling a list of Agile-related buzzwords, and seeing where that gets you, if you’re interested in a step-by-step guide.
Good luck, commander.
Great post, even if i still have no idea what Squirrely means… 😉
will be subscribing in future!
Doug
Pete,
I’ve got a couple questions in regard to your reasoning behind using story points as opposed to time. In the post you state, ” If a Senior Dev estimated a ticket as three hours, and a Junior is about to start their tenth hour on it, that’s going to be demoralizing. And if a Senior Dev is about to complete their third ten hour task in under an hour, they may get to thinking it’s time to see what’s new from Horse Ebooks.”
I don’t think this argument makes sense. First, shouldn’t the junior developer be estimating the amount of time it will take him to complete the ticket and not the other way around? Even if the senior developer does estimate the ticket, he has to consider the skill level of the junior developer and adjust accordingly. Likewise, if a senior developer is completing three 10-hour tasks in an hour, I would say that the estimates are being padded way too much. The senior developer needs to estimate his time better for his own tasks.
In both instances, I blame the senior developer for estimating tasks incorrectly for himself and junior developers.
– Chris
Chris,
Thanks for taking the time to comment. The idea is that for medium to large sized projects, there tend to be a lot of prioritized tasks to get through. There’s no guarantee on who’ll be doing a given task in four week’s time, and yet the business still wants estimates for them (which they get in via the Velocity).
While a Senior Dev could go through and estimate the work in advance, if you have differing levels of ability, then the Dev needs to know who’ll be doing a piece of work, how comfortable they are with that work, and so on.
There’s also a drive (and I think a well placed one) in Agile that you should be estimating as a team. That as good as a Senior Dev can be, there will always be parts they’ve missed, and that discussing the list of work to get through with the whole team helps knowledge share, helps teach other programmers, helps capture things the Senior hasn’t thought of, and helps build ownership of the project within the team.
So: in situations where the estimation is a collaborative task, and you don’t know in advance who will be doing them, you encounter the problems addressed in the article. In situations where someone has picked up a task not-yet estimated, and is asked to give an idea of how long it’ll take them to do, then sure, you’d expect them to estimate how long you think it will take /them/ specifically to do.
-P
Thanks for this post! I’ve worked on a few Agile run projects and honestly the story points always confused me. So your article really helped clarify! I like that stories are really a way to get a developer to commit to a task within a sprint. It’s less arbitrary than committing to hours.
But this sounds like a super concept, unfortunately, I’ve yet to see people meet their deadlines. It could be due to the fact that even though these projects were “Agile” the stories still had costs associated with it.
I’m finding the more that I read about Agile, the more I’m seeing the benefits of it for an internal project like a software update. Doesn’t work so well in client/team scenarios.
Any thoughts?
-Sheena
Sheena,
Thanks for taking the time to comment. I also, when I first started learning about Agile, wondered how it would ever work with an external client…
First, though, it’s worth considering that even internal projects have clients. They have clients from the perspective that someone somewhere is on the receiving end of whatever is built (and perhaps is the same person who can approve it or send it back), and they also have people whose budget the project is coming out of who can yay or nay it. Projects come in all sizes, too – one of the first Agile projects I worked on was at the BBC where we delivered iPlayer, a three year project that rolled the ability to watch TV over the internet out to the UK as a whole. A project without an external client, but still, a huge project!
Even though you’re estimating in Story Points, the PM is still feeding back to the clients, internal or external, on the velocity, and thus on the expected completion date of work.
So given that even internal projects have clients, where are the differences? People controlling budget for internal projects know that no-one is turning a profit margin on their work, so there’s an issue around trust and motivation there. Also, companies tend to communicate more frankly, openly, and efficiently with themselves than with the outside world. To me, then, the hurdles are trust and communication; if your external client trusts you, if you include them in the planning and delivery process (which Agile advocates), then some of these problems go away. It’d be a brave person who suggested there weren’t many more potential issues with working with external clients, though…
A final point to consider here is: what’s the alternative? Development teams switch to Agile because it gives them the ability to plan and communicate more effectively. Projects have to be sized and delivered somehow, and some (including me) would argue you’re likely to size it better, and thus it deliver it on time, when you’re using Agile.
-P
You hit the nail on the head with your comment about trust and communication. That really is the issue with all projects, internal or external. Which was the issue with the failed Agile projects I’ve worked on in the past.
I’ve yet to use Agile on projects I personally manage, but I’ve seen many companies use a hybrid of Waterfall & Agile, using the latter when making enhancements to a product.
Thanks for your article – I’m going to make it a point to use Agile on my next project! 🙂
Wow…asking developers for estimates? What a concept. Making them all agree on the relative complexity of a task? *mind blown*
I joke…sort of.
Well, Agile might have its weaker points, but it’s like democracy — we don’t know better alternative.
Nice article – a lot of great points! I’d like to discuss something however: I think there is a misconception between sizing and estimating here which should be clarified to give better context.
Sizing (using Fib. seq.) and velocity go hand in hand to help a dev team the ability to project an anticipated number of sprints toward completion of a backlog – as you pointed out. As the backlog changes (scope), and sizes change (during backlog grooming sessions), this will change as well. Some teams will use a cone of uncertainty (giving a range of sprints toward completion – based on best-case velocity and worst-case velocity, with the range tightening as the team stabilises and the velocity reaches a level of consistency). You would also factor in unknowns, risks etc into your sizing (generally: complexity, effort (“tediosity??”), doubt) – and adjust as those factors change (e.g. Big Scary Story would be huge initially, but as your PO takes time to break it down with your team and the team becomes more comfortable with the idea, you would adjust the size down as there is a combination of decrease in doubt, less effort expected, and lower complexity involved.
Overall this gives the product owner and stakeholders a good understanding of the level of assurance a team has with their ability to deliver each item in the backlog, and when they anticipate that this would be delivered – either in sprints via a release plan, or overall via velocity tracking.
Velocity, as you surmise, is an abstraction and not an equivalence to time estimation. I disagree, however, that the business is not interested in complexity and “tediosity”. I think velocity is your best way to engage the business/customer _because_ of the abstraction from time – they need to understand what factors are making stories large, and help to rein these factors in so that the team can give a better, more appropriate size. And I think it’s important to mention a key point: don’t commit to a velocity until your team has stabilised. The rule of thumb is that a stable team is achieved around sprint 4 (ie. after 3 sprints). “stable team” is also a key factor.
When it comes to estimating, you can only start to give yourselves confidence in your velocity by starting with time estimates. Once you find that your team’s sprint velocity is consistent, and your team is sizing well (and re-sizing well!), you can consider ditching estimates and work your sprints purely to points. And, regardless of whether your team is cross-functional, you still need to check whether you are capable of achieving your planned velocity for the sprint because…. *drum roll* you have to take *capacity* into account. This is also missing above.
If you have a fully cross-functional team with a consistent velocity, then you could account for this by merely applying a percentage to the velocity. 1 person in the team of 5 is away for 1 week out of 2 in the sprint, therefore you are 90% capacity for the sprint, maybe adjusting down to 80% for overall capacity lost bringing that team member up to speed upon return, or handing over work before going away, etc etc… there’s other ways of doing this – as long as it’s not forgotten.
PMs will use the above to help adjust velocity (well, truthfully I’ve only ever seen it done once in an Agile fashion – people tend to hope against hope that your velocity, if consistent, is sustainable).
At the end of the day, we want dev team to build confidence in their ability to commit, and build confidence for the PO in their ability to deliver against what they commit to.
Excellent post, thank you for explaining the intricacies of agile estimation with some humour behind it. Will definitely subscribe in the future.
Hello Pete,
I stumbled upon your blog from a web search on estimating software development. There are many portions in the blog that I agree with and have used in my daily work. I managed multiple disciplines of engineers and one pattern that frequently boggles my mind is the inability of software engineers to create an estimate for themselves. I worked as a software developer 10 years before becoming a manager and have faced many challenging situation as well. But the idea 15 year/20 year experience person cannot estimate to any accuracy at all is bewildering and at the same time frustrating.
On story points, I attempted to introduce the idea while introducing the agile metholodgy. It was not well accepted, it was difficult to get buy in from the engineers. So we stick to effort.
I am looking for ideas on how to improve effort estimation for my team especially the software team. Thanks for the blog. It was well written.
Hi Peter,
interesting estimating techniques and thanks a bunch for sharing.
C