Iteration Management – Post #5 – Estimates

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

If you ask people what they think of estimates, they’ll probably tell you that “estimates are always wrong”. But at the same time, management is taking those “wrong” estimates and treating them as a commitment to get work done by a certain date.

In reality, I think both of those things are true. The problem is that they seem so contradictory to each other, and this is where many teams get into trouble.

Many of you probably feel that estimating is a waste of time. It doesn’t make sense that you have to spend time each week estimating tasks when you could be using those hours to get things done.

I would love to live in a world where I didn’t ever have to estimate anything and all I would have to worry about is what I’m working on now and maybe what I have to work on next. Some of you might work in that kind of environment (maybe you’re in a small shop). But most businesses need to know how much things are going to cost, if Team A can complete a project before a certain date because Team B is going to need the functionality in place, if it’s worth it to build custom software or buy something off the shelf, or which consulting company to choose for a project. That’s the nature of smart business.

Or think of it this way – if you were going to build an addition on your house, would you not get several estimates from multiple builders and use those estimates as a major factor in who you picked to do the work? You certainly wouldn’t pick someone who said, “I do good work, so I’ll do the best that I can and then I’ll let you know how much it costs in the end.”

The fact is that if we want to be professionals, we need to be able to give good estimates, and we need to accept the fact that management is really asking for a commitment when they ask for an estimate. The whole reason that we estimate, regardless of the methods we use to do it, is so that we can tell management or the business when are going to get work done. Fortunately there are some things that we can do to come up with better estimates.

Small tasks

It’s much easier to estimate smaller things than larger things. What’s easier to estimate – the distance between your house and the one 3 houses down or the distance between New York and Chicago? You probably wouldn’t get either exactly right, but the margin of error will probably be less on the smaller distance.

The same is true when we’re breaking down a piece of work that we want to estimate. I like to break things down into the smallest unit that makes sense. Now that’s a pretty vague statement, but it really does depend on the situation. Ideally I like to break things down into the smallest testable unit that makes sense. That means that the feature provides some amount of value to someone (the business, IT, the dev team, etc.) and it can be tested and moved to production (or ready to go to production). There are always exceptions though – sometimes the smallest testable unit I can get to is still a week of work for 2 people, so then I’ll break the development down into smaller pieces (e.g. UI layer, business layer code, write some stored proc that is going to take awhile, set up an environment, etc.). Those technical tickets won’t be testable by themselves, but I’ll also have an overarching ticket that represents the testable unit (which is made up of the smaller techincal tickets). This at least lets us estimate smaller things so that we can be more accurate and have a better sense of how the work is progressing.

I’m not going to tell you what the maximum size of a ticket should ideally be, because every project is different. I’ve been on some projects where most tickets are under 4 hours of dev work, and I’ve been on other projects where the estimates were in days or weeks. The goal is to get the functionality broken down into the smallest chunk that makes sense for you so that you can get the estimate to be as accurate as possible.

Story Points or Hours?

There was enough here for it’s own post.

Categorization of work

On our team, we estimate analysis, development, and testing. So what counts as what? How does you categorize time spent by a developer writing automated tests? When a QA person writes a test plan, is that analysis or testing? What about meetings where you’re talking about a feature?

You can come up with your own rules of thumb, but here are mine:

Analysis

• Time spent doing business analysis (this one is obvious)
• Technical design
• Research into how something works, whether this is business-focused or technical
• Time spent by team members in meetings discussing the feature (remember, 5 people in a 1 hour meeting = 5 hours)

Development

• Coding, writing code, thinking about code, talking about the code, etc.
• Writing automated tests (if your QA people are writing end-to-end automated tests without developer involvement, I might categorize time doing that as QA)

Testing

• Manual testing
• Test planning
• Writing up bugs for a feature
• Writing end-to-end tests (see my comment in the Development section)

Other stuff (I might want to track the amount of time spent on these things, but not at a feature level)

• Team meetings not related to specific features (retrospectives, standups, iteration planning, other team meetings)
• Project management

How your team categorizes specific things doesn’t really matter, what’s important is that everyone is consistent and does it the same way so that you can get good data. You might want to check with your management as well because certain activities are capitalizable (like development, technical design, and testing) and others are not (like analysis).

The people doing the work should be the ones doing the estimating

This sounds pretty straightforward, but it’s really important. Let’s say that you know a lot about your application and you can complete feature X in 4 hours. But someone else who hasn’t been on your team as long or maybe isn’t as fast as you might take 16 hours. It’s not fair for you to give the 4 hour estimate and then hand it over to the person who is going to complete it in 16 hours. Maybe in that case you let the person re-estimate it at 16 hours, but that could throw your planning off. (This is another good thing about story points – when you estimate the size of a feature relative to other features, both developers might give the same estimate even though one will take 4 times the hours to complete it.)

I’ve been on some projects where we estimated a good portion of the work up front (because we had to bid on the project). That’s fine, but we never re-estimated anything. That led to lots of situations where a developer got assigned a ticket that they didn’t estimate, and once they had been working the task for as many hours as were estimated and they weren’t done, they started freaking out because they felt like they were behind, and this is when the sloppy code practices start happening. This happened because the people doing the work didn’t get a chance to give an estimate. If I give an estimate and I don’t finish it in time, then that’s on me, and I know it, so I don’t have any room to complain.

Nothing is more demoralizing than having someone else commit you to an estimate that you don’t feel is realistic. This just makes you feel angry, unmotivated, and unempowered. But if I make an estimate, then I’m a lot more likely to want to meet the estimate, even if it turns out that it’s going to take longer than I originally predicted.

Anything can be broken down

Any amount of work, no matter how complex, can be broken down into small, manageable tasks. The most complicated project is nothing more than a collection of simple tasks. The trick, of course, is identifying those simple tasks. But that scary project will become a lot less scary as you identify small units of work that need to be done. This exercise will also give you a better idea of all of the things you’re going to have to do, and you will be able to make better estimates on the small tasks.

This also applies to more nebulous roles like project management. Project managers are typically really busy and have to juggle numerous things at one time, but like anyone else, all of their work can be broken down, prioritized, tracked, and estimated. This will also free your mind because you have a system for keeping track of your work other than trying to remember everything in your mind (which is exhausting).

When to do the estimating

When the estimation happens depends on your team, your project, and how your team prefers to do it. I have a couple tips though.

Do the estimation as late as possible. It usually helps to have the work for the next iteration estimated so that you can do the capacity planning for the next iteration. You might have to estimate it earlier (so that you can plan out a release or bid on a project), but you might want to re-estimate that work when it gets closer to when you’re going to work on it in case the estimates have changed so that you can plan accurately.

Don’t have long estimation meetings. Some teams will have these meetings that last several hours long where the entire team goes through tickets and estimates them. I guarantee you that this will become everyone’s least favorite part of the week. Sometimes you might want to get everyone’s input on certain features, but for most things, you know who is going to do the work, so I would just let that person give their estimate so that you don’t have to tie up the whole team in mind-numbing meetings.

Remember the goal

Remember that however you estimate, the purpose is so that we can tell management or the business when are going to get work done. Use your intuition and come up with the best way that your team can estimate in order to meet this goal.

Read the next post in this series, Comparing estimation methods.