Release Planning

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

First, R.P. is that initial part of Scrum, where we plan the Product Roadmap and develop the first Release Plan. It is pretty important. We do it before we start doing Sprints.

Some people believe one myth about Agile (and maybe others). This first myth says: "we always leap in without looking or thinking." This is a myth, ie, 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 6 month planning 'phase' (for any project that I have ever been on... and I accept the possibility that there just might be a fundamentally different kind of project than I have ever experienced before).

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

Still, the Product Owner and the ScrumMaster must set a high-level time box and day-by-day time boxes for the Release Planning. And try to get the participants to stay within them. It is hard. But 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
6. Order the work (based on all the info developed above)
7. Decide on (a) scope and date (together), and (b) cost.

We 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. Left out some key things (well, not left out, but maybe not made fully transparent to some readers; assumed by me).

Having completed the R.P. 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) much much more on the same page about what the effort is really about. At a good medium level of detail. This is very very valuable.

Oh, yes, and we have the initial scope and date. The quality of those is technically termed 'crappy', so I minimize them as benefits. But soon, when revised and improved, they will become decent guesses.

Eventually (maybe up-front), this release plan must be developed further into a Product Roadmap (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 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)!