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.
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.
No comments:
Post a Comment