Refactoring the Release Plan

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

[This is one in a series of posts about release planning. Search (see right) on Release Planning to find many others.]

We had a product backlog.  The plan had some sort of scope, date and budget.  Still, 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.  Specifically, we start the first Sprint Planning Meeting.

That is not really the end of release planning, but the beginning of RPR (release plan refactoring).

Other people in Agile use other phrases for this, such as Product Backlog grooming or Product Backlog refinement.

It is absolutely fundamental to agile release planning to refactor the release plan frequently. I say (and 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 or learning, that we don’t have to change the release plan at all.  Ok, maybe this occasionally happens. At least we must evaluate that is the case.

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

1. changing the vision
2. improving the product backlog items (fewer, smaller, more, better)
3. identifying new user stories
4. re-evaluating business value (very key and very hard)
5. estimating or re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
6. taking a new look at the benefit-cost ratios
7. including new learning about risks, dependencies, learning, MMFS, etc.
8. re-ordering the work
9. revising the scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points — is one way of expressing it)
10. including the newest velocity expectations (based on recent trends).
11. 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.

These activities include:

1. breaking down stories or epics into small sprint-sized stories.
2. improving the stories or PBIs (wording, INVEST criteria, etc.)
3. estimating the business value of the smaller stories
4. estimating the effort of the smaller stories
5. answering questions from the Team about the expected sprint stories
6. adding detail (notes, acceptance criteria, etc.)
7. adding an Enabling Spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not ‘way’ ahead.]
8. checking that the Team thinks each story (likely to go in the next sprint) is ‘ready’ before the Sprint Planning Meeting

(Some of these are repetitive with the lost above.)

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

Let’s pause a moment.

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.  These independent input and output checks are 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 only 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 || The PO – The Team – The Daily Scrum » »