Comments on: Why There Should Not Be a “Release Backlog”

By: Mike Cohn

Mike Cohn — Wed, 06 Apr 2011 19:47:57 +0000

Hi Alexander–
I’m glad you liked the article. I would tend to treat this as one backlog. I’d most likely do it in Excel where I could set easy sorting columns, though. This is better (IMO) than the alternative of separate backlogs. With separate backlogs, the product owner cannot easily see the relative priorities between work on the major release and the planned service packs.

By: Alexander Korol

Alexander Korol — Wed, 06 Apr 2011 18:49:30 +0000

Great article. Thanks. Though I have some question regarding sharing backlog between several branches of development. Consider same team working on the major release and several service packs to prior releases. Most of the features planned for service pack also reach next major release but not all of them because the code base has changed. How would you treat the items in the back log in that case? Currenty we track them in a single backlog but that also causes issues understanding what features will be in what release. So currently I am trying to find alternatives to single Product Backlog approach although have not found anything workable yet.

By: Eric Krock

Eric Krock — Sun, 23 Jan 2011 00:32:48 +0000

I agree that if product owners are wasting time moving stories back and forth between a release backlog and an overall product backlog, that would be a bad thing. In practice, I’ve never had that problem. As I describe in Use Multiple Backlogs, I started off by tagging user stories/feature requests in the product backlog to put them into maintenance, minor, and major release “buckets,” plus a “future” bucket for all the good ideas I didn’t expect to make the next major release. I was always conservative about putting things into these buckets (biasing towards sticking things in “future” unless I though there was a high probability the ticket would in fact be done on the next maintenance/minor/major release), so I didn’t in fact waste time moving things around. This practice saved enormous time when it came time to create the “release plan” for a given release. I only had to review the items I’d put in the appropriate bucket (s) for the upcoming release and any finer-granularity buckets (e.g. review both maintenance and minor buckets when planning a minor product release). Then we could track a burndown chart for the work we approved for the release plan. I continued a version of this approach (“future” tagging) when I moved to another company that was in fact using Agile to get an unorganized 1800 ticket backlog under control. Now I use an Agile tool with explicit release support. This discussion may get a bit confused by a semantic question. If you tag user stories on the master product backlog, is that creating a separate backlog? One might view the practice I outline as simply informative tagging on user stories to save time in release plan development–overlaying these tags on top of the standard master backlog. What I *do* know is that when I’ve got a large team of smart developers and lots of customers all submitting good ideas for a long-lived product whose lifespan spans a decade or more, I don’t want to have to review every idea ever submitted each time I plan a new release. This approach also saves me from having to maintain a precise total order on all the user stories in the system, which although a good theoretical goal, ultimately gets a bit imprecise. Can I *really* say for certain that this item is the 138th most important item on the total backlog and the next one is really the 139th? All that said, I think your approach of keeping a total order and then defining the release as a “bubble” floating part way out on the product backlog is a perfectly viable alternative as well. Part of which approach you choose may have to do with the lifespan of the product and project. If the team is only writing user stories for the current project/release and not keeping track of other requests it knows it won’t do for this release, the single backlog without tagging or bucketizing will work really well. When you’ve got a continuous stream of existing and incoming ideas, many of which you know you can’t address in the current project/release, but which you want to capture for future evaluation, bucketizing gets more attractive.

By: Mike Cohn

Mike Cohn — Tue, 14 Sep 2010 14:26:43 +0000

Hi Matt–
I’m glad you’ve found an approach that works for you. There are contexts when a release backlog can be a good idea.

By: Matt Block

Matt Block — Tue, 14 Sep 2010 11:43:51 +0000

In general, I have to agree with you Mike. However, I we are successfully using a Release Backlog and I’m not sure how we’d manage without one. I think one of the keys here is we are really managing several products the fit together into a suite. We do releases at a suite level and don’t have a full team for each product. So the best way we have found to make progress on each product in a release with the limited resources is to have individual product backlogs that each product owner manages up until we start release planning. At that point we pull the top items from each product backlog into a release backlog. We generally don’t fill it to capacity right at the beginning and we review at the end of each sprint with all product owners so any adjustments can be made. It is working quite well for us. I’ve written a post about that and a few other things we are doing.

http://www.developmentblock.com/2010/09/managing-a-multi-product-agile-team/

By: Ringing true: Robust planning and Agile « Positive Incline

Ringing true: Robust planning and Agile « Positive Incline — Wed, 10 Jun 2009 11:34:28 +0000

[...] thought-provoking post Why there should not be a release backlog from early February is still attracting comments four months later, and it prompted me to go back [...]

By: Mike Cohn

Mike Cohn — Fri, 05 Jun 2009 11:30:46 +0000

To help business people see the importance of “it’s better to be roughly right than precisely wrong” (quote from JM Keynes), I usually ask them casually, “so, how much money are you going to make [save] on this project?” And I’ll get back, “We expect to make between $4-5 million in sales in the first year.” And I reply, “Oh, I didn’t want a range. I want to know exactly how much you’ll make. I don’t mean to the nearest penny–after all, you don’t make me estimate to the hour. But to the nearest dollar, how much do you expect to make?”

Ask the question the right way and you make your point. Ask it the wrong way, you get fired! But, said the right way to the right person, it does get the point across–we could decide that the revenue part of the equation is fine as a range so we should be able to make appropriate business decisions even with the cost/schedule part of the equation as a range.

By: Simon Cromarty

Simon Cromarty — Fri, 05 Jun 2009 10:20:17 +0000

Thanks Mike. I’ll focus on 1 figure for story points and a range for velocity.
Dan’s detailed article is excellent.

I’m also working on how to translate “rather roughly right than precisely wrong” into something stakeholders who are used to single point commitments (that may or may not be met) are willing to work with?

By: Mike Cohn

Mike Cohn — Fri, 05 Jun 2009 02:35:49 +0000

Hi Simon-- From experience I have found that putting a range around individual story estimates and around velocity is both too complicated and tends to double-count the risk and uncertainty that we are attempting to account for. I do occasionally meet teams to which I'll recommend two-point (never 3) estimating in story points. The technique for doing this is covered in the Agile Estimating and Planning book in the chapter on Buffered Planning. The estimates are combined then into a point estimate using the square root of the sum of the squares approach. By the way, for more information on using optimistic and pessimistic bands for release planning, see this recent post by Dan Bergh Johnnson.

By: Simon Cromarty

Simon Cromarty — Thu, 04 Jun 2009 12:48:15 +0000

Great article. I’m really excited to see these concepts being introduced to the mainstream!

Interestingly the optimistic/most likely/pessimistic approach is a classic old concept that works very well for estimation in many areas.
It’s actually part of the PERT estimation model and is a lesser known aspect of the 1950′s PERT techniques.

I was introduced to the concept of “PERT+2″ about 4-5 years ago.
That is: using opt,ml,pess to calculate a weighted average + 2 standard deviations to give a statistical “95% confident” estimate.

My previous team adopted this approach for size estimation and then applied this to a single point capacity forecast for the team. This is a flip of what you’re describing but to the same end.

Our estimate & delivery predictability dramatically improved over the course of a single project to the point where the team were delivering exactly what they said they would when they said they would every time.

Since then I have trained teams in using this same concept for Size estimation in ideal days in conjunction with relative t-shirt sizing for early estimates and team estimate sharing & balancing throughout the cycle(variations on wideband delphi or planning poker)

I’m trying to bring my work in line with established agile good practices as my teams embrace agile estimating & planning.

We’ve been looking at story points & planning poker for size estimation but have recently started discussing the use of opt/ml/pess for velocity as a means of communicating a delivery range to our stakeholders.

My questions are:
As size is typically much harder to establish than team capacity, should we be looking at using ranges for size (e.g. story points) rather than velocity?

Would things just get too complicated if we estimated ranges for both story points *and* velocity?