Building complex innovative products is, of course, hard.
So, in that context, what is the purpose of Release Planning in Scrum/Agile?
We will not provide a complete explanation here, but we will give a few key ideas.
1. A consensus view of the 'same' elephant. We want all the team members to see the whole product and to start to see the same whole product. We think this is typically the most valuable thing.
2. Think first, but not think too much. This is a neat trick -- getting some people to think enough before they start, and also helping others not get stuck in 'analysis paralysis'.
I find that many people want to know 'perfectly' a certain set of information before they start. Meaning: They want to wait and study too long. I find this seeking for 'perfection' is mis-guided. It typically does not include enough consideration of what it costs us not to know 'X' before we start. (If the cost could be real high, then slowing down to learn 'X' makes more sense).
I think each team should have a good fight about how much to 'study' before starting to Sprint.
3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed. My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But it establishes a starting point for improvement. So, for several reasons, it is necessary.
4. Establishing an Early Warning System. I was just working with a large client who has a big, multi-team and multi-year effort. Some on the team think they will get done 'early'. And some think they will be 'late' as usual (this is said from my own personal experience that most waterfall projects are late...and this organization is just transitioning from waterfall).
In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can take counter-measures to address the problem.
So, the Release Planning sets up the ideas (velocity, story points to be completed, Business Value of the features, etc) that go into the Release Plan. And the Release Plan, with its implied 'ideal velocity', can become the Early Warning System.
Since, in this case, the Chief Product Owner is leading this effort, this gives him great incentive to get the whole group to do professional Release Planning now. So that, for example, refactoring of the Release Plan will take less effort later. So, the CPO needs to explain and explain again why the whole group wants a good Release Plan sooner rather than later. (Only if they want to do it, will they do it well.) Not an easy job. Do-able, but not easy. Especially for beginning Product Owners.
So, in that context, what is the purpose of Release Planning in Scrum/Agile?
We will not provide a complete explanation here, but we will give a few key ideas.
1. A consensus view of the 'same' elephant. We want all the team members to see the whole product and to start to see the same whole product. We think this is typically the most valuable thing.
2. Think first, but not think too much. This is a neat trick -- getting some people to think enough before they start, and also helping others not get stuck in 'analysis paralysis'.
I find that many people want to know 'perfectly' a certain set of information before they start. Meaning: They want to wait and study too long. I find this seeking for 'perfection' is mis-guided. It typically does not include enough consideration of what it costs us not to know 'X' before we start. (If the cost could be real high, then slowing down to learn 'X' makes more sense).
I think each team should have a good fight about how much to 'study' before starting to Sprint.
3. Establishing a project plan, with a date estimate for the first release and a cost estimate. In most organizations, something like this is usually needed. My experience is that, aside from the discussions about risks and impediments, this is usually the least valuable output. But it establishes a starting point for improvement. So, for several reasons, it is necessary.
4. Establishing an Early Warning System. I was just working with a large client who has a big, multi-team and multi-year effort. Some on the team think they will get done 'early'. And some think they will be 'late' as usual (this is said from my own personal experience that most waterfall projects are late...and this organization is just transitioning from waterfall).
In this case particularly, the group (everyone in the group) needs an early warning system that can tell them whether they are likely to hit the date or not. (A date and a high-level scope has been defined, but the detailed requirements are undefined.) For example, the earlier the group knows there is a problem, the earlier it can take counter-measures to address the problem.
So, the Release Planning sets up the ideas (velocity, story points to be completed, Business Value of the features, etc) that go into the Release Plan. And the Release Plan, with its implied 'ideal velocity', can become the Early Warning System.
Since, in this case, the Chief Product Owner is leading this effort, this gives him great incentive to get the whole group to do professional Release Planning now. So that, for example, refactoring of the Release Plan will take less effort later. So, the CPO needs to explain and explain again why the whole group wants a good Release Plan sooner rather than later. (Only if they want to do it, will they do it well.) Not an easy job. Do-able, but not easy. Especially for beginning Product Owners.
3 comments:
Ciao!!, nice article!, i loved the content!, wow!!, i'm not a good reader but definitely i am good in appreciation..^^..keep it up^^..
Great post!! Thanks for sharing such an wonderful information ...
Great Post. Was a good read Thank you.
Post a Comment