Joe's Booklet on Agile Release Planning

I have a first draft, version 1.01 of a booklet that ties together all the posts I have made (well, most of them) on agile release planning.

Here: http://agileconsortium.pbworks.com/w/page/57940361/Joe%27s%20Release%20Planning

It is a bit rough, needs more editing. My apologies for that.

If you have a moment to read it or just look at it, and give comments, please do.

Joe

Refactoring the release plan

At the end of the last post, we had complete the initial release plan.
What were the key outcomes?

[This is one in a series of posts about release planning. See here.]

Well, the plan had some sort of scope, date and budget. Usually on Day zero the quality is 'crappy' to use the technical term. As it must be, given how much we don't know on Day zero.

The real win was that we now have 'everyone' on the same page, at a useful middle level of detail: what is this elephant?  What are we about to do... 

And then we start the first sprint.  Or more specifically, we start the first Sprint Planning Meeting.

But that is not really the end of release planning. But the beginning of RPR (release plan refactoring).

It is absolutely fundamental to agile release planning that we refactor the release plan frequently. I say (and many others that I greatly respect say) that we must refactor the release plan every sprint. Every sprint.  Ok, maybe during every 10th sprint there will be so little change, that we don't have to change the release plan at all.  Ok, maybe this very occasionally happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:

* changing the vision (all of these are 'if needed')
* improving the product backlog items (more, fewer, smaller, better)
* re-evaluating business value (very key and very hard)
* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
* taking a new look at the benefit-cost ratios
* including new learning about risks, dependencies, learning, MMFS, etc.
* re-ordering the work
* doing a new scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points -- is one way of expressing it).
* including the newest velocity expectations (based on recent trends).
* adjusting the buffers and communicating the new, new release plan (scope, date, budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backlog information to make it ready for the Team to be successful in doing the Sprint work.  Some people use phrases such as 'product backlog grooming' for this. (Note: I think 'product backlog grooming' can have other meanings too, depending on who is using the phrase.)

These activities include:
* breaking down stories or epics into small sprint-sized stories.
* improving the stories or PBIs (wording, INVEST criteria, etc.)
* estimating the business value of the smaller stories
* estimating the effort of the smaller stories
* answering questions from the Team about the expected sprint stories
* adding detail (notes, acceptance criteria, etc.)
* adding an agile spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not 'way' ahead.]
* checking that the Team thinks each story (likely to go in the next sprint) is 'ready' before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming are completely different.  I think this way of thinking is unhelpful.  One of the purposes of release planning is to make the work in the sprints more successful. Release planning is not completed until, for each sprint planning meeting, we have 'the stuff' ready for a successful sprint planning meeting. Among the key success criteria of that meeting is: we used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner.  We know from long experience in our industry that 'knowing what the customer wants' is extremely hard. Extremely. The business stakeholders are people whose time is scarce and yet these people are essential to us in getting a much better fix on what the customer really wants (or what the firm wants).  We want them in the Sprint Planning Meeting, agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.  Because these independent input and output checks are so vital, we must use their time efficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower level release plan refactoring. And when people say 'product backlog grooming' they often mean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint.  We improve it.  This is absolutely key to adaptive planning.

Release Planning: Completing the Plan

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

(Please see this post for a list of all the posts on Release Planning.)

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.  They 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/are 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?  Ok, three sprints, how many features are 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 (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 project.  The other minutes are used talking about the game, taking breaks, eating lunch, getting interrupted, answering questions, reading the email, going to company meetings, etc, etc.  Maybe some 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% has 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.

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 the plan)... 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 we 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 "buffers" (aka padding, 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.

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?"  (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 the 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.