Estimating: How, why, don't

Multiple organizations, multiple teams, one truth: Estimating is haaaaaard.

So at this point in my career, I’ve been on a bunch of different teams in a few different organizations. Some big. Some small. Some with very junior staff. Some where everyone had a good 10-20 years experience on me.

On every single one of these teams, story and task estimation was a struggle. I want to talk about why that is, why we bother estimating at all, and how we go from story points to estimating projects.

The point of points

Assuming you’re doing some variation of scrummy Agile, you’re probably using points to estimate your work items. These points probably come in the Fibonacci sequence variety (i.e., 1-2-3-5-8-13). Based on anecdotal evidence, there’s a 75% chance you hate these numbers with a fiery passion that consumes your soul.

The main problem with story points is that few people actually use them in a way that makes sense. It’s not uncommon for me to hear points directly tied to time, especially when a product owner or stakeholder is looking at a work board and saying, “Oh, so I’ll have that feature in 3 days?”. This is not what you want.

The best uses of story points are those that use them as measures of relative effort. That is, how much work does the average team member need to do for this task relative to how much work previous tasks were. This can’t be tied to time for a few reasons:

1. Relative effort is a pretty blurry metric that takes teams a while to normalize on.

2. Teams are made of individuals, so a 3 for one person will take more time than a 3 for a different person.

3. Every time the team dynamic changes you have to re-normalize. This takes time.

4. Relative effort can (and will) change over time.

“So,” I imagine you saying, “why would I bother with this at all?”

Well, I’m glad you asked, imaginary voice in my head! The answer is that even though the points themselves aren’t super helpful, velocity is. For the uninitiated, velocity is the average number of points you complete per sprint over time. This number helps you figure out how much work to pull in to the next sprint but, more importantly, it can help you avoid burnout.

Using velocity to protect your team

There are three really big ways you can use velocity to help prevent burnout. First, let’s assume you have a team that has been consistently doing 20 points a sprint. You, a perceptive team leader, have noticed that your team also consistently talks about not having time for training, or needing a vacation, or being tired.

Thanks to velocity, you can know how much work to pull in to give your team a bit of a break. In this example, maybe you only pull in 15 points worth of work so they can slow down a bit. Then, next retro, you talk about how the team felt about the amount of work. Do they feel less overwhelmed? Refreshed enough to return to the old pace? Velocity gives you the data to know when your team isn’t working sustainably and a means to correct the problem.

The second big win for velocity is when someone approaches you with a feature that can’t possibly be done when they want it done. I think I’m not the only one who’s been in a situation where the scrum leader pulls in a crazy amount of work, looks at the team, and says everything there is top priority and needs to be done this sprint. If you’ve been in this position, it’s nice to be able to say, “Whelp, that’s double our regular velocity, so we’ll need at least two sprints to do it.”

There are certain types of people who will push until they can push no further. Having the numbers to back you up when you push back is a great way to protect your team from unrealistic expectations and unattainable deadlines.

Thirdly, if you are forced to rush development and code while tired, the numbers can help you show why you shouldn’t do that again. For example, say your team generally knocks of 20 points a sprint, then they force you to do the crazy thing and you slog through an exhausting 40 point sprint. Thing is deployed, the business says yay, everyone is happy.

Then, inevitably, the bugs start rolling in. I feel pretty strongly against pointing bugs. Partially because if they were predictable enough to point they probably wouldn’t have happened in the first place. Mostly because I want my scrum leader to panic a little when our velocity suddenly drops to nothing as we scramble to fix the quality problems a rushed development causes.

A huge, sudden drop in velocity gives you data to back you up the next time you’re asked to forgo quality for speed. Make the pain loud and visible. Show them how it hurts. Hard numbers are great at convincing people they don’t want a repeat of past mistakes.

Wait … so how do I estimate projects then?

I have created for you a handy chart.

The fact is, I’ve been in many, many, many projects where hours and hours were spent trying to think up all the features and point them. Every single time we’ve had to throw out those estimates because the team changed, the market changed, the requirements changed, the … (this list is eternal).

Unless your project is extremely small, it’s probable that you have far too many unknowns for anything like an accurate estimate. Your actual release date will either be moved back or you’ll rush to meet the arbitrary deadline you set and quality will suffer. Or, if you’re unlucky, both of those things will happen.

Instead of estimating big projects, the best thing to do is get it down to the smallest pieces with value and release early and often. No, you won’t have a big exciting launch. You’ll have something that brings value quickly and you won’t have tortured your team with long, grueling meetings. You’ll also make your stakeholders happy as they see progress sooner and more consistently. Win-win!

Louder for the people in the back

Estimating is hard. Points are ambiguous. Unknowns are unpredictable.

Instead of trying to solve the unsolvable, focus your estimates inward and use them to help and protect your team. Keep your pace sustainable, your features small, and your quality high. After all, a happy team that isn’t struggling with burnout is far more likely to stay with you for the long haul.