Release Planning

November 20, 2010

This is a short post to summarize my recommendations for Release Planning.

First, release planning is what we do before we start Sprinting. It is where we plan the initial Product Roadmap and develop the initial ‘plan.’ It is pretty important. We do it just before we start doing Sprints.

Some people believe one myth about Agile (and maybe others). This first myth says: “Always leap in without looking or thinking.” This is a myth, i.e., incorrect. We must look and we must think first. But, how much?

Within Agile there is always this tension, between thinking just enough and YAGNI (you ain’t gonna need it). Each team must resolve this tension its own way. Experience has shown that we learn most from real experience. So, suffice to say we do not, in Agile, have a six month planning ‘phase’ (for any project that I have ever been on… and I accept the possibility that out there there just might be a fundamentally different kind of project than I have ever experienced).

So, should it be done in one day? In three days? In three weeks elapsed time? The simple framework of Scrum does not answer this question. Use common sense (which is quite uncommon). (My bias is toward one day.)

Still, the Product Owner and the ScrumMaster must set a high-level time box and day-by-day time boxes for the Release Planning. Try to get the participants to stay within them. It is hard. The law of diminishing returns tells us not to waste that ‘extra’ time.

OK, what to do?

  1. The Vision
  2. Build the Product Backlog (stories)
  3. Organize the stories with Business Value (I like BV points from Priority Poker)
  4. Estimate the effort of the stories (using relative Story Points)
  5. Discuss risks, dependencies and other things

THEN

  1. Order the work (based on all the info developed above)
  2. Decide on (a) scope and date (together) and (b) cost

Generally assume that the team is a constant cost per Sprint, so once you know the number of Sprints, you can easily calculate the cost.

Over-simplified. I left out some key things (well, not left out, but did not make them fully transparent to some readers; assumed by me).

Having completed the Release Planning you have achieved two main benefits.

  1. You have established an “early warning system,” which, when improved, can give you some advanced notice if your effort is getting into trouble.
  2. You have all the “pigs” (and others) more on the same page about what the effort really is, and this was done at the right level of detail. This is very valuable.

There is the initial scope and date — the quality of those is technically termed ‘crappy,’ so I minimize them as benefits. Soon, when revised and improved, they will become pretty decent guesses.

Eventually (maybe up-front), this release plan must be developed further into a Product Road map (I don’t really care what name you call it). Typically this is a rolling 12-month plan. After the current release, this is typically at a pretty high level (small to medium epics). Most businesses or products need about a 12-month plan. Some less, some more.

To close on a semi-controversial note: NO Sprint Zero! We did some release planning, now let’s do a real Sprint (with a demo of working software at the end)!

Facebooktwitterredditlinkedinmail

« « No man is an island, entire of itself || How I teach – 1 » »

Posted in: Better Agile, Release Planning
Tagged: Tags: , , , ,

One thought on “Release Planning”

Leave a Reply