The scope of a product release needs to be identified as part of the release planning process.
The release planning process is for coming up the scope and the schedule for a software product release.
There are internal factors from the development, but there are also external factors, for example, the constraint or the request from marketing or product management department.
Depending on the market condition, sometimes, the time to market may be important and the duration for a given release may be shorten. One or few features drive the release schedule and the rest of product features are added more like catching up a train.
--
The process looks like systematic, but there are still many judgement.
Are the estimation accurate? How accurate is enough? How can we come up an estimate if we do not know what the work looks like?
Is stack ranking possible and meaningful? There are long term goal and shorten goal. How do we balance among the different goals?
Resource pools may not be that easy to distinguished among each other. Some people are constraint resources, Those are people who cannot be easily replaced. There are people who are assigned to certain area but can be borrowed to work on something else. Shouldn't we plan the resource according to the constraint resources?
When a work involves multiple resource pools. Timing may be another factors. The total resource level may be sufficient but they cannot work on all projects assigned to them at the same time. Schedule can be a constraint too.
The release planning process is for coming up the scope and the schedule for a software product release.
There are internal factors from the development, but there are also external factors, for example, the constraint or the request from marketing or product management department.
Depending on the market condition, sometimes, the time to market may be important and the duration for a given release may be shorten. One or few features drive the release schedule and the rest of product features are added more like catching up a train.
--
- Identify the candidate projects
- Elaborate the scope down smaller units that are small enough for estimations
- Determine the stack ranking among the projects
- Identify the resource pools and the resource level for each pool
- Ask each involved disciplines to come up the estimations.
- Use the accumulative total resource requirements from the top of the list and compare the projects with the resource level.
- Select the projects above the level and move the projects to the candidate list for the next releases.
The process looks like systematic, but there are still many judgement.
Are the estimation accurate? How accurate is enough? How can we come up an estimate if we do not know what the work looks like?
Is stack ranking possible and meaningful? There are long term goal and shorten goal. How do we balance among the different goals?
Resource pools may not be that easy to distinguished among each other. Some people are constraint resources, Those are people who cannot be easily replaced. There are people who are assigned to certain area but can be borrowed to work on something else. Shouldn't we plan the resource according to the constraint resources?
When a work involves multiple resource pools. Timing may be another factors. The total resource level may be sufficient but they cannot work on all projects assigned to them at the same time. Schedule can be a constraint too.
No comments:
Post a Comment