Comments on: When Should We Estimate the Product Backlog

By: Mike Cohn

Mike Cohn — Mon, 14 Feb 2011 23:19:09 +0000

Hi Karen–
I agree: many organizations struggle with this quite a bit.

By: Karen Favazza Spencer

Karen Favazza Spencer — Mon, 14 Feb 2011 15:42:58 +0000

From my experience, it seems that some groups don’t understand the differences between Roadmap, Release & Sprint planning. For my money, the definition of each should be tied to the timebox. Saying you have a 6, 8 or 9 month Release, with an every growing backlog is a great way to increase risk and inject confusion into the development process. This time frame is more appropriate for a Roadmap approach. I’d much prefer having a few Epics at the beginning of the Sprint, drawing a line in the sand at 3 to 4 months out, and spending the first day of each Sprint figuring out what we’ll do next to sizing 200 stories up front. Of course, it’s at the business’s discretion to RTM any Release. Divorcing the Development Release from the RTM strategy allows the business to adjust their roadmap without wasting development time estimating large number of stories that may need to be rewritten or eliminated.

By: Mike Cohn

Mike Cohn — Thu, 03 Sep 2009 16:07:31 +0000

Hi John-- Yep, sounds backwards to me. I would, however, continue to estimate that initial story only to the extent the PO needs that estimate to prioritize the feature. Say I want I new custom report design feature in a product. If that costs 400 story points, I don't want it. If it costs 50, I want it now. If it's 200, I want it but I'll wait a bit as we have higher value stuff to do first. My new book, Succeeding with Agile, will cover the role of user experience designers / interaction designers on Scrum/agile projects. You can pre-order Succeeding with Agile now on Amazon or access it immediately on Safari.

By: John Esser

John Esser — Thu, 03 Sep 2009 14:17:18 +0000

Hi Mike, I have another kind of issue. In our group, we estimate stories when they come on the backlog. Then, after this initial estimate, many of the stories (epics, small ones, etc.) are taken by the Product Owner/UX team and designed. After this design we typically have to 1) reestimate again, and 2) break the story down based on the design that was given to us. This seems a bit backwards or out of step from how I think it should happen. Wouldn’t the PO team work on breaking the stories down into manageable pieces before doing the UX design, etc.? There just is not a lot of information on how a UX/visual design team can effectively interact in the scrum process. Any suggestions or insight?

By: Mike Cohn

Mike Cohn — Fri, 28 Aug 2009 13:17:21 +0000

Hi Kevin–
I don’t see why this other group can’t work with your estimate in story points. In fact, it should be easier for them to calculate ROI. All they need to do is calculate how much a story point costs on average. To do that, look at how many points your team or department did last year or last quarter. Divide that into the amount of many the team or department was paid during that period and you’ll get a dollar (or Euro, etc) amount per point. I did this recently with a team and got $3000/point. If the other group is assessing a 3 point story, they can estimate it as costing $9000.

This will be a $9000 based on actual data. If you had told them “12 hours” they would have multiplied 12 hours times some cost-per-hour but that would have been a bad estimate because we don’t know how accurate the 12 is. Using story points here should be easier and should help them get a better ROI estimate.

By: Kevin Johnston

Kevin Johnston — Fri, 28 Aug 2009 07:20:07 +0000

What is the best way to handle the following situation:
We have a team that want to setup a change management process, we have multiple systems which themselves contain multiple products, A team (not the dev team) has started to record change requests and are asking us for estimates of “how long” it will take to do a particular CR so that ROI can be done on the CR to allow prioritisation to take place!
We the developers really want to view CR the same as any other item on our backlog and simply estimate it relatively in terms of Story points to allow prioritization to be done by a PO. I can appreciate that they think they need a duration to help them justify the change request, I feel it is ok to give an estimate in hours for ROI purposes but not for planning! any thoughts appreciated

By: Mike Cohn

Mike Cohn — Fri, 23 Jan 2009 20:25:59 +0000

Hi Kelly-- In general, I try to avoid re-estimating a product backlog item at all. I would only do so if you are convinced you were wrong about its *relative* size. The chief problem with re-estimating is that your backlog of finished items then contains a mix of items estimated before you did the work and ones after you did the work. That causes you to almost certainly misstate velocity compared to the product backlog of upcoming work with is (of course) all estimated before having done the work. The topic re-estimating is fully covered in the Agile Estimating and Planning book.

By: Kelly

Kelly — Fri, 23 Jan 2009 19:11:36 +0000

When would you resize a backlog item? We’re mid-sprint right now, and realize that a backlog item was oversized. We have prioritized items in the backlog that we can take on to fill up the sprint; but we’re a new scrum team and want to be sure that we’re capturing velocity as close to ‘real’ as possible. Should we resize it during the sprint, or wait until the retrospective and handle it more as a ‘lessons-learned’?

By: Mike Cohn

Mike Cohn — Tue, 14 Oct 2008 03:56:21 +0000

Hi Jeremy–

I probably wasn’t very clear earlier. I don’t suggest grouping items because they are highly similar or in the same file. I suggest grouping them in logical areas to facilitate estimating. It would take forever to estimate 1200 items. There have to be some functional groups you can make from them. Suppose the product is Microsoft Word. We might group all the fixes in stylesheets, all the fixes in table support, all the fixes in pagination, all the fixes in display, etc. Then the team reads all the items in one group and puts an estimate on the collection. I would compare this to looking at the items in your shopping cart and estimating the total cost of the cart vs. estimating the cost of each item.

If that’s not possible for some reason then telling the product owner to give you 150 based purely on desirability of the feature (as you describe above) would be a perfectly fine approach.

By: Jeremy

Jeremy — Mon, 13 Oct 2008 16:29:33 +0000

Thanks Mike and Artem for your quick responses. The 1200 backlog items are actually specific bug fix requests or small enhancements in all different areas of a 10 year plus legacy product. (some of the requests go back at least 5 years since being entered into our change management system.) There is a chance that some of them could be grouped together, but in all actuality they are independent efforts.

We are asked to estimate them independently. So while I agree with the idea that we need to know the cost before we can determine the highest priority, it could take a significant investment to estimate all 1200 items. (plus with new items coming in on a regular basis from our user community). Would you suggestion be to get the PO to come up with the top “150″ without estimates and then estimate only those? (And then keep ensuring that a top 150 exists. As we complete some work others are moved onto that list?)