In Part 1, we talked about the primary problems with estimating software development accurately:
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.
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 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.
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.
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.
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.
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.
We've covered six good ideas from the Agile Estimation Process:
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.
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.
Excellent post, thank you for explaining the intricacies of agile estimation with some humour behind it. Will definitely subscribe in the future.
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.
Well, Agile might have its weaker points, but it's like democracy -- we don't know better alternative.
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.
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.
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.
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.
Usefully estimating software projects is difficult, but not impossible.
A lack of understanding about why we estimate, what to estimate, and how to estimate leads to a breakdown of trust and communication between developers and managers.
Developers end up feeling guilty that they're not meeting their estimates, and at the same time defensive: they were just estimates after all, right? Managers feel exasperated that everything is taking three times as long as it should. What are they doing all day?
This article is about fixing your estimates, and your estimation process. It's split in to two parts - the part you're reading, titled "How to Estimate like an Adolescent", and the part you're not yet reading, titled "How to Estimate like an Adult - What to Steal from Agile".
As an aside, if you're in a position where someone else is estimating work you're doing, get out. The work will be late, you will be blamed, and you will be miserable. Programming is meant to be fun, and setting yourself up for accusations of professional incompetence and the niggling feeling that maybe you are incompetent is the antithesis of fun. Seriously, get out.
The FIRST robotics season has begun! I'm working with a high school team to build a robot in 6 weeks that will compete in sports-like competitions. Robots compete on random teams of three against other teams, in several qualifying matches and then elimination rounds. The theme for this year is "Aerial Assist", and the game encourages passing and teamwork among alliances, which appeals to me as the Iowa St. basketball team is currently 2nd in assists per game and makes passing a point of emphasis. A nice animation of the 2014 FIRST game is here.
I have been frustrated throughout the preseason of FIRST by the number of students on the team. There are about 90 kids that show up, and with only ~15 mentors the it gets pretty overwhelming. This is much larger than typical FIRST teams.
But, this year, in build season, we are dividing everyone up into "corps", with one mentor per corps. Corps are dedicated to different pieces of functionality in the robot, and combine students who work in mechanical, fabrication, controls, and software. For example, this year we have a shooter corps, a drive corps, a ball-pickup corps, an autonomous corps, among others. The autonomous corps is responsible for getting the robot to work during the autonomous period of the game: everything from mounting a camera system to detect which goal is "hot" to automatically driving the robot around to score the ball and end up at the best place for the teleop part of the game. I'm the mentor for the autonomous corps. Having a smaller group of students who are focused on a specific subset of the functionality is much more enjoyable than having twenty students who are good at code but don't know what task to be working on. Everybody can understand their piece better when the robot functionality is divided up.
We are also using Agile, which I've been advocating. Within Agile, teams write down a backlog of tasks to do, then plan for the week-long "sprint" selecting tasks from the backlog and committing to getting those tasks done. At the start of each day, team members talk about what they did yesterday, what they will work on today, and what is getting in their way, in a short standup meeting. The combination of splitting up tasks into week-long and then further into day-long tasks and taking personal responsibility to get them done also helps keep everybody focused and busy.