Release Planning: Completing the Plan

[This post is one of a series on Release Planning. The series starts here.]

As discussed in the previous post on Release Planning, the user stories are now ordered.

Now we must complete the Release Plan.

So, we must make the trade-off between scope and date.

There are three ways to do this:

1. Fixed Release Date.  We will release every X months or Y sprints.

Some teams or firms prefer to have a fixed release date. It makes things simple.  It makes managers and others realize that we will release.  The only question is exactly what will be in the release.

2. Fixed scope.  We will release when all of the scope (all the stories or PBIs in that scope) is done.

3. Trade-off.  We understand our velocity and go down the Product Backlog a ways. And ask: two sprints, umm, how many features are done?  Not enough.  Ok, three sprints, how many features will be done?  Ok, four sprints, umm, customers would really like to see another release, the market needs it, but do we have enough?  Ok, five sprints, umm, I think we have enough.  Let’s shoot for that.  — It is that kind of trade-off.

This requires that we know our velocity.

Estimating Velocity

With an existing team, you might already know their velocity. With a new team, you must guess.

So, we do a calculation to get an educated guess.

First, for the 1 story point reference story (the reference story for effort)… how many ideal person days would it take?  The Team huddles around the story and reaches a decision.  Imagine the number is 1 SP = 1.5 ideal days.

Imagine the Team has 6 doers of ‘real work.’

Imagine the Team will do 2 week Sprints.

Let’s assume the focus factor is 60%. That means, out of an 8 hour day, roughly 60% of the minutes are usable for the effort or project.  The other minutes are used talking about the ball game, taking breaks, eating lunch, getting interrupted, answering questions for other projects, reading the email, going to company meetings, etc, etc.  Maybe some useful work, but not work on this project.

Calculation:

2 weeks = 10 days.

6 x 10 = 60

60 x 60% = 36

36 x (1-40%) = 21.6

21.6 / 1.5 = 14.4 Story Points for the 1st Sprint.

—-

We subtract the 40% as a start-up “cost” for the 1st Sprint.  The Team is learning Scrum, the Team is “forming, storming, norming, performing…”, the Team always wants to over-estimate what they can do in a timebox.
For the 2nd Sprint, we subtract 20%.  For the 3rd Sprint, we subtract maybe nothing.

You may find that these rule of thumb numbers need to be adjusted for special situations.  But they seem to work for most start-up teams.

—

36 x (1 – 20%) = 28.8

28.8 / 1.5 = 19.2 story points for 2nd sprint

—

36 * (1) = 36

36 / 1.5 = 24 story points for 3rd sprint

And so on…

“Communications Plan”

I tend to put pressure on new Product Owners to release earlier.  They are mentally too tied to the concept of the 100% – 100% rule.  That nothing can be released until everything is done.  This is almost always just wrong.  Hence, I always ask for an earlier release than whatever he is first thinking.

Once the PO and Team agree on the scope and date, we then have to talk about the “communications plan”, as I call it.

If the Team works with a manager who truly understands adaptive planning (meaning that the current plan will be revised and improved every sprint… this is only the first guess at what will happen)… then tell that manager the truth.  “Here’s what we guess, this is what we are worried about.  This is our feeling about how it is likely to change.”  And maybe you have contradictory feelings.

But often some key managers do NOT understand adaptive planning. These “tough” managers (or customers) want you to give a fixed date, and then deliver to that date.

Then you are stuck. So, we have to do what we used to do in waterfall. Add some “buffer” (aka padding, contingency, etc, etc) to the date.  For “problems”, for new stories to be identified later, etc, etc.

It is hard to guess how much buffer to add.  We have no additional magic.  Use common sense.

But, we do strongly suggest that you protect yourself and your Team. Do not get them in a situation of a Death March, trying to meet an impossible date.  More about this later….

And then we talk about, “ok, how will we communicate the date in such a way that we end up being perceived as a success?”  (Almost always, the key issue is the date.) You have to start setting expectations that the date will change if other things change (substantially), and they are likely to change substantially.  This is not one conversation by the PO, but a series of conversations by and with many people.  It is over time that they start to see and feel the power of adaptive planning.

For some of you, the issue is not so much “communications plan”, but “what do we put in the contract”.  Too big a subject for this post.

Finalizing the Plan

Assuming you have “business stakeholders” as I described them earlier, then always you have to review the release plan you have with them.  Get their buy-in or comments or adjustments.  This of course may affect the communications plan.

So, this is most of the basics.  A bunch of issues we have not addressed.  Some I will address in the next post.

 

« « Self-organization of the Team || Refactoring the Release Plan » »