The last responsible moment is an idea that gets a great deal of play in the Agile community. One way that concept comes about is when figuring out how soon to do certain things, such as when to estimate product backlog items.
But before I dive into the question of timing, I think it’s worth expanding the question and asking whether teams should estimate product backlog items at all.
Should a team estimate product backlog items?
Yes, I did it. I invoked the #noestimates argument.
I asked the question about whether teams should estimate product backlog items at all to encourage some critical thinking about why teams estimate.
At one point, critical thinking was a key aspect of working in an Agile manner. Teams were encouraged to examine the practices they followed and determine why they followed those practices.
I’m not sure that kind of critical thinking is encouraged as much as it should be, even in organizations that claim to be operating in an Agile manner.
Here’s a chance to reverse that trend.
Stop for a minute and ask why your team is estimating in the first place. Perhaps it makes perfect sense to estimate. You may have a wide range of sizes for your product backlog items and you have to differentiate between them.
Or perhaps your team has found a way to consistently get to product backlog items that are all about the same size. Estimation at this point is a waste of time because all of your product backlog items generally take the same amount of time.
So should a team estimate product backlog items? I don’t know. As I suggested in a previous post: “Think about why you need estimates. What decisions are they helping you make, then pick the approach that provides the right balance of information, accuracy, and effort so that you can make that decision. The approach you select may differ depending on your situation. Choose wisely.”
It depends on your context. Some teams should estimate. Some teams shouldn’t bother.
When you estimate is all about balance
So let’s assume it makes sense for your team to estimate. When should you do it?
You want to do it soon enough so that the information the estimates provide help you make key decisions, but you want to do it late enough that you have as much information as you can get.
Not too helpful? Yeah, I know. So let’s break that advice down a little bit.
One reason to estimate is to help you make prioritization decisions. When you’re trying to decide whether to tackle a particular feature, you should seek to understand how much work something takes and consider that along whether it provides value. If you can put a little bit of work into something that provides a lot of value, it’s a no-brainer that you should do that.
Another reason to estimate is to determine when you are going to get done, or how much you’ll be able to get done by a certain time. You’re usually asked that question fairly early on. Which happens to be exactly the point in time when you don’t really have sufficient information to answer that question both accurately and precisely.
The longer you wait to answer that question the more accurate and precise you can be, but you may find that you’re not being as helpful as some in your organization like.
So a good approach may be to do some extremely rough estimation fairly early on. Expend very little energy to come up with an (admittedly very imprecise) answer and promise to revise that answer with a better idea as you proceed through your work.
Then, as you get closer to delivering a particular backlog item, estimate again. Use information about the size of similar product backlog items and information about the product backlog item in question to come up with a fairly good idea of the size of the new item in relation to others. If you’re using Scrum or a similar framework that uses timeboxed iterations, that means you estimate product backlog items today that you plan to deliver an iteration or two down the road.
When do you estimate product backlog items?
When I’ve been on teams that estimated product backlog items, we’ve followed the approach I described above. I realize that other teams have taken different approaches that work for them. If you’ve found a different timing of when to estimate, share them in the comments.
