Your Effort Estimates are Probably Wrong

Please read and let me know your thoughts! I'd love to hear about your experiences. I'm not a certified expert. I don't have scientific statistical analysis to back up my statements. I've just been at it for a while...using a bunch of different approaches. I've learned a few hard lessons. Sadly, I've re-learned a few of them a couple times too.

Same Old Story (Points)

It can feel like one (or more) of the same things are happening on a constant basis:

• You're listening to your colleagues (and / or yourself) explain why what was originally estimated to be a user story with a story point value of five, should probably have been an eight
• You're catching your colleagues (and / or yourself) putting in extra hours in order to complete a user story that is taking longer than expected to complete
• You're working with your team on effort estimates and letting yourself imagine the best-case scenarios for getting the work done

If you're like most of the teams I've been a part of over the years (Agile or not), you regularly find yourself in a position where you regret the effort estimates that were placed on pieces of work. More precisely, in my experience, you probably regularly find yourself wishing you had estimated the work to be larger than you originally guessed.

I'd like to explore some of the problems I've seen with work item estimation, some of the ways I've seen it improve, and what I think can be done to limit some of the pain it can cause an entire team.

Why Does It Even Matter?

Does it matter if your estimates are wrong? Does it matter how wrong? It's entirely possible that for your team, it doesn't much matter if your estimates are off...even by a lot. But, for most teams it does matter. A large reason why we bother estimating work effort at all is so that we can plan. Once we have a sense of how much we can get done in a certain time frame (a single sprint, a set of four sprints, etc.), we can start to make smarter predictions about when things can be accomplished. If you know your team can take down seventy-five story points a sprint, a backlog that has been fully sized at around 600 points can be burned down in roughly eight sprints. This is powerful information for anyone attempting to build a roadmap for the future. It doesn't just help with software scheduling...it assists with marketing plans, fiscal planning, staffing, user engagement, etc.

The more accurate we can be with our work effort estimation, the more empowered our entire organization can be.

Hyper-Optimism

I'm no psychologist, but optimism seems like it's probably a good thing. A positive outlook on potential outcomes seems like a healthy and happy way to go through life. People generally don't like to be around negative people, and I think most people don't feel particularly happy with themselves when they're being pessimistic. It's romantic to think of optimism being the driving force behind an endless list of human accomplishments. No doubt optimism plays a hugely valuable role in all kinds of endeavours...but...what if I told you that optimism might be killing your team's ability to accurately estimate?

Imagine a scenario where your team is working to assign story points to backlogged work items. You are in a meeting with a number of gifted and capable colleagues discussing the elements of the work to be done and deciding how much effort each item will take. Everyone shows a clear understanding of the problems and are doing some light brainstorming on how they can be solved. It comes time to cast your vote and it seems like everyone has a perfectly clear idea of the attack plan. You make your vote and the team settles on a point value. If you're like most teams, you've likely let your optimism get the best of you. You've spent too much time allowing yourself to imagine the best-case scenario where little to nothing goes wrong. Where no unexpected problems arise. Maybe someone (maybe you?) raised a few concerns about the age of the code that needs to be touched or the potential fragility of the engine that it requires. But those comments felt too pessimistic, too alarmist, too negative...and were generally disregarded. Well...you did it. You set yourself up for a wrong estimate as soon as anything (even one thing) goes against expectations.

Now whoever will be working on that item will be in one of the positions I described at the start. Trying to cram more work into a smaller space. It never feels good. It's also fertile ground for mistakes. Want to  know what's worse? Because you underestimated the size of the work, you left more room in the sprint to allow more work in. And that work is likely underestimated too!

In this scenario, work will often be 'hidden' through working extra hours or cutting corners. If the work is completed, you've created the illusion that the work was estimated correctly, thus setting the expectation that the same amount of work can be completed in subsequent cycles. An undesirable merry-go-round...sprint after sprint.

Optimism and positivity have their place. But don't let your team get away with only imagining the best-case scenarios. It will come back to bite you. A culture where it's okay to imagine the things that could (will) go sub-optimally will serve you. Go so far as to assign a 'doomsday' member in each planning effort. Their job can be to come up with all the ways something could sabotage the best case. Incorporate a designated amount of time in each estimation where everyone brainstorms the potential gotchas. It's not about being negative or pessimistic, it's about approaching work realistically, with your eyes wide open.

A Change Won't Do You Good

Everything is constantly changing in software. Teams, technologies, projects, people, the list goes  on. It's inevitable.

A major factor in being good at beginning to trust your team's effort estimates is the ability to compare estimates to actuals over a length of time. If your team is continually in a state of change, you will never be able to build up the estimation stockpile that you need in order to become more and more accurate. Two separate teams evaluating the same work item could give significantly different estimates. Similarly, the same team but with a 25% change in membership will provide different outcomes as well. It's no different when changing the technology a team uses, a process they're used to, or the project altogether. These changes will produce unreliability in estimates.

It would be foolish to assume you can eliminate changes. But if estimation accuracy is to be a major factor in your organization, favouring the limitation of changes can only be beneficial.

Estimation Optimization

It's never going to be perfect. But if we can set ourselves up for it to be as accurate as possible, we can all enjoy life a little more. Getting the work done without the added pressure of being behind schedule is very likely to produce better quality work. Not to mention happier workers who aren't putting in extra time to pay the estimation piper.

Getting optimized estimates only helps the entire organization plan better. Better planning should lead to less abrupt changes and course corrections...which leads to better estimating!

Take those rose-coloured glasses off (at least for planning meetings!) and help remind people in your organization that consistency over time plays a vital role in beginning to find your groove with accurate estimations.

Thanks for reading. I would really love to hear your thoughts and see your reactions to what I've said. I look forward to the conversations.