Release Management Process - for post-project support or product development
After the formal end of the project - the work does not end, but only begins. It is necessary to implement the functionality that is not included in the main content of the project, correct non-critical errors that did not impede the launch, and maintain the flow of changes and incidents accompanying the operation process. At the same time, it is necessary to organize the process in such a way as to take into account the priorities of requests, technical dependencies, and leave time for analyzing the required changes.
The “release management” process, one of the ITSM process stack, offers the solution for formal prioritization and grouping user requests (change requests, incidents) into common delivery packages - “releases”.
This article briefly covers the following topics:
')
When is it appropriate to apply the process in addition to incident management and change management? Of course, in each case the set of criteria is different, but the scenarios listed below are a good reason to think about releases:
In addition, under certain conditions of planning and organizing release phases, the entire delivery process can be as close as possible to the Scrum method (regular delivery of changes, with the highest value for the customer), thus gradually moving to using flexible approaches in organizations that are not very predisposed.
Activities:
Selection of requests for changes and incidents to the list of what is planned to be done, an initial prioritization, analysis of interdependencies and a preliminary assessment of the labor costs for analysis and development are carried out.
Result:
All requirements contain a high-level assessment of complexity and recommendations for grouping into a release based on the scope of changes and / or technical dependencies.
Taking into account these assessments and recommendations, based on the business priorities of the customer and the available resources of the contractor, a group of requests for changes and incidents is accepted for analysis. Appeals not included in this list are returned to the general pool and will be evaluated in the next releases.
Resources:
Activities:
A detailed analysis and evaluation is carried out, specifications are prepared for changes selected on the basis of customer priorities. The selected requirements are fully analyzed and approved by the customer, technical specifications are worked out, and a detailed assessment of labor costs has been carried out.
Result:
Fully analyzed change requests are prepared for final confirmation of the release's content. Requests for which the analysis or approval is not completed are returned to the common pool. They are candidates for analysis (end of analysis) in the next release.
Resources:
Activities:
Receipt of resources from performers (for development) and customers (for testing). Estimate total release budget (if applicable). Final coordination with the customer of the content of the release, based on the readiness of individual requests, priorities, estimated budget, available resources.
Result:
Formed the final content of the release.
All change requests included in the final content of the release are transferred to development. The remaining change requests are returned to the shared pool. Since these changes have a high degree of readiness - they are candidates for the next release.
Resources:
Activities:
Development and correction of defects for all applications included in the final release content. Internal testing and preparation for acceptance testing.
Result:
Applications included in the release content are developed. Transfer to customer for acceptance testing.
If the development for a change from the content of the release is not completed, then, based on the analysis of technical dependencies, the issue of either transferring the change to the next release or delaying the release of the current release is considered.
Resources:
Activities:
Conducting acceptance testing by the customer, correcting the detected errors, making the necessary improvements (as agreed)
Result:
The content of the release has been tested, accepted by the customer, and is ready for distribution.
If the acceptance of a change from the content of the release is not completed, then, based on the analysis of technical dependencies, the issue of either postponing the change to the next release or delaying the release of the current release is considered.
Resources:
Activities:
The package of changes is transferred to operation. Publish a new version of the product in a productive environment.
Result:
Changes are transferred to the production environment and are available to the customer.
Resources:
Activities:
Completion of work on the change package: the necessary formal steps (documents, acts, accounts), discussion of the release results within the team.
Result:
Formal completion of work. Process improvements.
Resources:
This planning is carried out at the very beginning of the implementation process, and refers to the process as such - and not to individual releases, since the duration of an individual release will not change.
The fundamental stability of the release calendar in this case allows the parallel execution of several releases with an offset relative to each other. In this case, the main task of scheduling the stages of releases is to balance the speed at which changes are delivered to the customer and to ensure optimal utilization of team resources.
What will definitely change is the resources available at each stage, in different releases (people get sick, go on vacation). But given the above planning constraints, this will only affect the amount of changes delivered, not the schedule.
In general, planning releases with a fixed duration, and the dependence of the delivery volume on the availability of resources, is a relatively simple task. As a result, the process turns out to be as predictable and rhythmic as possible, in many respects close to Scrum.
In the case when releases are planned on the basis of a given amount of changes recorded before the beginning of the analysis stage, and the deadlines are estimated from complexity and resources - the release manager requires detailed planning of the duration of each stage. In this sense, releases correspond to the standard “waterfall” model of development, planning is no different from project planning.
With this model of organization of releases, it is rather difficult to organize parallel execution of several releases, since each must be planned separately and parallel releases must be considered as a portfolio of projects in terms of the use of resources.
Regarding delivery dates, releases planned from volumes also do not offer the customer greater certainty as compared with the design approach:
Thus, the use of releases with scheduling on delivery volume does not in any way simplify the operational activity of supporting the application in comparison with the project, and requires appropriate management resources. Also for the customer, an estimate of the delivery time of the required changes remains very approximate.
In the future, we will discuss only the details concerning releases with a fixed duration.
Since the stages are defined, their interrelationships are fixed, and the duration of each stage will be unchanged, scheduling a single release is not difficult. The main question that needs to be determined is the duration of each of the stages.
To do this, you can try to use the following data that you may have on the basis of a completed project:
Having information about the ratio of costs and the composition of the team - you can determine the ratio of the time stages. The development phase can serve as a good basis for fixing the final durations (since it is precisely the development cost estimate that is the most methodologically elaborated) - the duration of all other stages will be considered from it.
The duration of the “Deployment” and “Closure” stages is usually set fixed, since they are not directly dependent on the amount of changes. Of course, if the dependency in your case exists, it should be taken into account.
After determining the duration of each of the stages, you can proceed to the creation of a "project calendar" - the designation of the dates of each of the stages. If you are planning a regular release of updates — say, monthly, quarterly — it is most convenient to build a calendar plan by “reverse planning”, starting from the expected release dates.
In any case, use tools designed for scheduling (such as MS Project). This is especially important when creating a calendar with overlapping releases in time, since it will be necessary to carefully control the loading of resources.
As can be seen from the description of the stages of release, at each stage different resources are involved and the loading profile is not homogeneous:
Thus, the expected step to optimize resource utilization is the parallel execution of two (or more) releases, planned so that resources constantly switch between the same stages of subsequent projects. That is, for example, the analyst, having completed the analysis stage for the R1 release, switched to the R2 analysis stage. Similarly - for developers and customers.
With all the evidence, the implementation of such a plan is a realizable, but not trivial task.
The main difficulty lies in the fact that the duration of the stages of analysis and development / testing is generally unequal, which leads either to an overload of some resources or to the downtime of others.
In case you build a release management process with parallel phases, the release schedule should take into account overlapping and resource loading. It is quite possible that the quality schedule of concurrently executed releases will impose additional requirements on the composition of the team - so that the overall "development" of Analysts and Developers, taking into account the duration of the stages, will be equal.
Let's see what is the expected volume of the contents of the release.
The volume of requests for changes that can be analyzed by the scope of the Scope phase represent the maximum uncertainty. Indeed, until the analyst begins to analyze the application, does not understand what is at stake, it’s very difficult to say how much the full analysis will take. Of course, a preliminary analysis of applications at the “Draft” stage will help to give a first assessment, but it can be used to distribute applications among analysts, depending on their specialization and experience. In addition, it is necessary to take into account that the analyst is involved in acceptance testing - so, the analysis of requirements and the transfer of the development to the analyst does not end the load on the analyst.
Thus, the first evaluation of the content of a release can be given in terms of the “number of applications for analytics to release”. The most pessimistic assessment of “1 change request for analytics in release” is worth starting with. After the statistics on the "performance" of analysts is collected - the assessment of the content will become more accurate.
The job of analyzing the technical implementation, based on the requirements collected, also takes time and effort — from the development team. As a rule, the group leader is responsible for the preparation of technical specifications and development cost estimates.
It may happen that the preparation of specifications takes more time and does not fit into the scope of the “Scope” stage - then the change request is automatically “dropped” from the contents of the current release.
Assess the complexity of the preparation of technical solutions is possible only after the completion of the analysis. As an optimistic assessment, you can always keep "everything that was prepared by the analyst - will be worked out by the technical leader", although, of course, this is not always the case.
Based on the prepared requirements, the technical specification turns out to be a fairly accurate estimate of the development costs - it will be used later.
Evaluation of the development costs, the available resources of the Developers, the availability of the Customer for participation in the acceptance testing - all this determines the final content of the release.
So, without taking into account the transfer of ready-made requests from previous releases - the volume of release content is limited above by the number of applications analyzed (determined by the resources of Analysts). Restrictions on developer resources can further reduce the release volume.
I will share some observations about the problems accompanying the release process. Of course, in another organization, most likely, the problems will be their own and will have to deal with them independently. But at least - some general points must be borne in mind.
When planning parallel releases, a situation arises where all resources — Analysts, Customers and Developers — must “switch” between releases. In particular, the switch scripts are as follows:
"Context switching is bad." Indeed, this leads to a decrease in efficiency, loss of focus on the task, and may lead to delays at key stages of the process.
As an auxiliary measure to minimize the effects of switching, it is necessary to coordinate them additionally - this is the load on the release manager.
Since releases are planned “one by one” or even “in parallel” - any delay in any stage, and, accordingly, non-release of resources usually affects both the current and not the next release through a shortage of resources.
Based on the design of the stages of release and transition between them - the greatest negative effect has a delay in the stages of development and testing. The analysis phases (“Draft”, “Scope”, “Approval”) have the opportunity to lower the content of the release by transferring unfinished applications to the next release - and this is perceived by the customer, usually easier than transferring from the approval of the content of the release.
This is the main reason for the violation of the release calendar. Since the process at each stage implies that the team takes on obligations, based on the available resources - there is always a procedural opportunity to reduce the amount of delivery to meet the deadlines. However, very often - under pressure from the customer, or in pursuit of "development" (which often happens during contract development) - the team takes on "increased obligations", which are immediately reflected either in terms or quality (and most often - and on that and on the other).
As a measure, you can use a pessimistic estimate of the amount of resources when fixing the contents of the release at the stage of “Approval”. In general, the topic of “underestimating the task / reassessment of one’s own forces and how to deal with it” is very controversial. And the decision is very dependent on the organizational environment in which the team works.
Quite often during the analysis it turns out that the scope of the task does not fit into the time frame of the “Work in progress” stage - the required volume cannot be developed and delivered within a single release.
If it is not possible to increase the resources of developers, there are two possible ways to solve this problem:
Subjectively, the first option is more preferable, since it allows you to maintain the regularity of delivery and present at least some of the functionality in the current release.
However, it is quite possible, the second option may be preferable from the point of view of loading the resources of developers.
The handling of incidents and the elimination of defects obviously take up the resources of the team (to a greater extent - the Developers, but sometimes Analysts). In addition, often eliminating non-critical defects that have known workarounds may have less business value than the required changes. Hence, an obvious desire to consider the tasks of eliminating defects (or providing additional services) in the general context of planning the content of a release — to do what is important.
On the other hand, the elimination of defects can be approved by the customer as an a priori most important task - thus, resources for the elimination of defects will have to be allocated as a priority.
In any case, it is necessary to take into account the presence of defects in assessing the available resources that can be allocated to the content of releases.
Regardless of the approach to assessing the necessary resources, the inclusion of tasks to eliminate defects in the contents of releases can be useful in analyzing the technical dependencies of all changes that the team is working on.
A major advantage of the release process (especially for releases with a fixed duration) in the eyes of the customer is a pre-announced release date, usually tied to specific calendar points (for example, monthly, quarterly). This allows you to build a transparent and rhythmic process, with the expected check points (transitions between stages) and the expected results at each point. In addition, the customer is directly involved in determining the content of the release by setting priorities.
For the team supporting the product, the process provides the opportunity to realize the optimal loading of their resources, and manage the scope of work, delivering changes on time and with high quality. Also, after several completed releases, based on the collected statistics, it will be easier for the team to justify requests for additional resources in response to increasing customer requests.
The “release management” process, one of the ITSM process stack, offers the solution for formal prioritization and grouping user requests (change requests, incidents) into common delivery packages - “releases”.
This article briefly covers the following topics:
')
- process applicability - when it makes sense to implement it
- main steps of the process, activities, involved resources and results
- release planning: calendar, volume, parallel execution
- some delivery issues in releases
Applicability of the process
When is it appropriate to apply the process in addition to incident management and change management? Of course, in each case the set of criteria is different, but the scenarios listed below are a good reason to think about releases:
- The initial period of post-project support: a significant amount of changes, problems with prioritization, the need to effectively enforce customer expectations
- The process of product support: the need to organize a process that optimizes the use of all available resources within the existing budget.
- A large percentage of change requests affect intersecting subject areas or lead to technical dependencies — you must explicitly group changes in order to optimize development or testing work.
- The process of directly delivering developed product changes to a product is “expensive,” from any point of view: from coordination, to the direct costs of distributing changes.
In addition, under certain conditions of planning and organizing release phases, the entire delivery process can be as close as possible to the Scrum method (regular delivery of changes, with the highest value for the customer), thus gradually moving to using flexible approaches in organizations that are not very predisposed.
Process steps
The process consists of a sequence of steps. In different implementations of the process, some stages may be combined, or may be called differently - but the general principle remains
1. Draft
Activities:
Selection of requests for changes and incidents to the list of what is planned to be done, an initial prioritization, analysis of interdependencies and a preliminary assessment of the labor costs for analysis and development are carried out.
Result:
All requirements contain a high-level assessment of complexity and recommendations for grouping into a release based on the scope of changes and / or technical dependencies.
Taking into account these assessments and recommendations, based on the business priorities of the customer and the available resources of the contractor, a group of requests for changes and incidents is accepted for analysis. Appeals not included in this list are returned to the general pool and will be evaluated in the next releases.
Resources:
- Analysts (lead analyst)
- Customers
- Release Manager
2. Scope
Activities:
A detailed analysis and evaluation is carried out, specifications are prepared for changes selected on the basis of customer priorities. The selected requirements are fully analyzed and approved by the customer, technical specifications are worked out, and a detailed assessment of labor costs has been carried out.
Result:
Fully analyzed change requests are prepared for final confirmation of the release's content. Requests for which the analysis or approval is not completed are returned to the common pool. They are candidates for analysis (end of analysis) in the next release.
Resources:
- Analysts
- Customers
- Developers (Tech lead)
3. Approval
Activities:
Receipt of resources from performers (for development) and customers (for testing). Estimate total release budget (if applicable). Final coordination with the customer of the content of the release, based on the readiness of individual requests, priorities, estimated budget, available resources.
Result:
Formed the final content of the release.
All change requests included in the final content of the release are transferred to development. The remaining change requests are returned to the shared pool. Since these changes have a high degree of readiness - they are candidates for the next release.
Resources:
- Customers
- Release Manager
4. Work in progress
Activities:
Development and correction of defects for all applications included in the final release content. Internal testing and preparation for acceptance testing.
Result:
Applications included in the release content are developed. Transfer to customer for acceptance testing.
If the development for a change from the content of the release is not completed, then, based on the analysis of technical dependencies, the issue of either transferring the change to the next release or delaying the release of the current release is considered.
Resources:
- Developers
- Analysts
5. Testing
Activities:
Conducting acceptance testing by the customer, correcting the detected errors, making the necessary improvements (as agreed)
Result:
The content of the release has been tested, accepted by the customer, and is ready for distribution.
If the acceptance of a change from the content of the release is not completed, then, based on the analysis of technical dependencies, the issue of either postponing the change to the next release or delaying the release of the current release is considered.
Resources:
- Customers
- Analysts
- Developers
6. Deployment
Activities:
The package of changes is transferred to operation. Publish a new version of the product in a productive environment.
Result:
Changes are transferred to the production environment and are available to the customer.
Resources:
- Maintenance service
7. Closure
Activities:
Completion of work on the change package: the necessary formal steps (documents, acts, accounts), discussion of the release results within the team.
Result:
Formal completion of work. Process improvements.
Resources:
- Release Manager
Release Planning
Like any activity, releases need to be planned. Fortunately, release management is a process, and therefore, when planning, you can count on the fact that the stages, their relationship does not change. However, to plan a release schedule, you need to decide in principle on the approach to delivery:
- If, introducing releases, you also plan to ensure the regular release of new versions - then, most likely, the duration of the stages should be fixed at some optimal values.
- If releases are used only as a grouping of individual change requests, and the total duration of the release should be estimated based on the scope of work and resources, the assessment of the duration of the stages is not fundamentally different from the planning of any project.
Planning Releases with a fixed duration
This planning is carried out at the very beginning of the implementation process, and refers to the process as such - and not to individual releases, since the duration of an individual release will not change.
The fundamental stability of the release calendar in this case allows the parallel execution of several releases with an offset relative to each other. In this case, the main task of scheduling the stages of releases is to balance the speed at which changes are delivered to the customer and to ensure optimal utilization of team resources.
What will definitely change is the resources available at each stage, in different releases (people get sick, go on vacation). But given the above planning constraints, this will only affect the amount of changes delivered, not the schedule.
In general, planning releases with a fixed duration, and the dependence of the delivery volume on the availability of resources, is a relatively simple task. As a result, the process turns out to be as predictable and rhythmic as possible, in many respects close to Scrum.
Release Planning on Delivery Volume
In the case when releases are planned on the basis of a given amount of changes recorded before the beginning of the analysis stage, and the deadlines are estimated from complexity and resources - the release manager requires detailed planning of the duration of each stage. In this sense, releases correspond to the standard “waterfall” model of development, planning is no different from project planning.
With this model of organization of releases, it is rather difficult to organize parallel execution of several releases, since each must be planned separately and parallel releases must be considered as a portfolio of projects in terms of the use of resources.
Regarding delivery dates, releases planned from volumes also do not offer the customer greater certainty as compared with the design approach:
- the duration of each release can initially be estimated only on the basis of the initial estimate - the probability of error is large
- work delays at each stage are not procedurally corrected by decreasing the content - delays accumulate
Thus, the use of releases with scheduling on delivery volume does not in any way simplify the operational activity of supporting the application in comparison with the project, and requires appropriate management resources. Also for the customer, an estimate of the delivery time of the required changes remains very approximate.
In the future, we will discuss only the details concerning releases with a fixed duration.
Release Scheduling
Since the stages are defined, their interrelationships are fixed, and the duration of each stage will be unchanged, scheduling a single release is not difficult. The main question that needs to be determined is the duration of each of the stages.
To do this, you can try to use the following data that you may have on the basis of a completed project:
- approximate relationship between analyst and developer resources for one task. For example, “if an analyst spends 5 people * days on requirements, then development and testing costs will be about 10 people * days”.
- similarly, the ratio between requirements analysis and the duration of acceptance tests
- team composition: number of analysts, developers, testers.
Having information about the ratio of costs and the composition of the team - you can determine the ratio of the time stages. The development phase can serve as a good basis for fixing the final durations (since it is precisely the development cost estimate that is the most methodologically elaborated) - the duration of all other stages will be considered from it.
The duration of the “Deployment” and “Closure” stages is usually set fixed, since they are not directly dependent on the amount of changes. Of course, if the dependency in your case exists, it should be taken into account.
After determining the duration of each of the stages, you can proceed to the creation of a "project calendar" - the designation of the dates of each of the stages. If you are planning a regular release of updates — say, monthly, quarterly — it is most convenient to build a calendar plan by “reverse planning”, starting from the expected release dates.
In any case, use tools designed for scheduling (such as MS Project). This is especially important when creating a calendar with overlapping releases in time, since it will be necessary to carefully control the loading of resources.
Simultaneous execution of multiple releases
As can be seen from the description of the stages of release, at each stage different resources are involved and the loading profile is not homogeneous:
- Analysts are maximally loaded at the Scope and Test stages, less loaded at the Draft and Work in progress stages. During Work in progress, analysts are often involved in working with developers, clarifying requirements if necessary.
- Developers - the most loaded in the period of Work in progress. Depending on the implementation of the process, at this stage, work is underway on change requests that are included in the approved content of the release. At the same time, at other times, they may be engaged in the correction of defects, refactoring of the code, and other useful things.
- Customers are involved in the period of requirements collection (Scope) and acceptance testing (Testing). In other periods - the involvement of the customer is insignificant.
Thus, the expected step to optimize resource utilization is the parallel execution of two (or more) releases, planned so that resources constantly switch between the same stages of subsequent projects. That is, for example, the analyst, having completed the analysis stage for the R1 release, switched to the R2 analysis stage. Similarly - for developers and customers.
With all the evidence, the implementation of such a plan is a realizable, but not trivial task.
The main difficulty lies in the fact that the duration of the stages of analysis and development / testing is generally unequal, which leads either to an overload of some resources or to the downtime of others.
In case you build a release management process with parallel phases, the release schedule should take into account overlapping and resource loading. It is quite possible that the quality schedule of concurrently executed releases will impose additional requirements on the composition of the team - so that the overall "development" of Analysts and Developers, taking into account the duration of the stages, will be equal.
Determining the contents of the delivery for a fixed release duration
Let's see what is the expected volume of the contents of the release.
Requirements analysis phase
The volume of requests for changes that can be analyzed by the scope of the Scope phase represent the maximum uncertainty. Indeed, until the analyst begins to analyze the application, does not understand what is at stake, it’s very difficult to say how much the full analysis will take. Of course, a preliminary analysis of applications at the “Draft” stage will help to give a first assessment, but it can be used to distribute applications among analysts, depending on their specialization and experience. In addition, it is necessary to take into account that the analyst is involved in acceptance testing - so, the analysis of requirements and the transfer of the development to the analyst does not end the load on the analyst.
Thus, the first evaluation of the content of a release can be given in terms of the “number of applications for analytics to release”. The most pessimistic assessment of “1 change request for analytics in release” is worth starting with. After the statistics on the "performance" of analysts is collected - the assessment of the content will become more accurate.
Preparation of technical solutions
The job of analyzing the technical implementation, based on the requirements collected, also takes time and effort — from the development team. As a rule, the group leader is responsible for the preparation of technical specifications and development cost estimates.
It may happen that the preparation of specifications takes more time and does not fit into the scope of the “Scope” stage - then the change request is automatically “dropped” from the contents of the current release.
Assess the complexity of the preparation of technical solutions is possible only after the completion of the analysis. As an optimistic assessment, you can always keep "everything that was prepared by the analyst - will be worked out by the technical leader", although, of course, this is not always the case.
Based on the prepared requirements, the technical specification turns out to be a fairly accurate estimate of the development costs - it will be used later.
Fixing the contents of the project
Evaluation of the development costs, the available resources of the Developers, the availability of the Customer for participation in the acceptance testing - all this determines the final content of the release.
So, without taking into account the transfer of ready-made requests from previous releases - the volume of release content is limited above by the number of applications analyzed (determined by the resources of Analysts). Restrictions on developer resources can further reduce the release volume.
Known Issues
I will share some observations about the problems accompanying the release process. Of course, in another organization, most likely, the problems will be their own and will have to deal with them independently. But at least - some general points must be borne in mind.
Context Switching for Parallel Releases
When planning parallel releases, a situation arises where all resources — Analysts, Customers and Developers — must “switch” between releases. In particular, the switch scripts are as follows:
- The analyst completed the analysis (“Scope” stage) for the R1 release and switched to collecting the analysis for the next R2 release. He will have to switch back to the R1 release context to support acceptance testing.
- The Customer has a similar switching pattern, especially if its requests for changes are made in subsequent releases.
- For developers, context switching is less pronounced - only if you need to switch between a new development and old defects.
"Context switching is bad." Indeed, this leads to a decrease in efficiency, loss of focus on the task, and may lead to delays at key stages of the process.
As an auxiliary measure to minimize the effects of switching, it is necessary to coordinate them additionally - this is the load on the release manager.
Resource conflicts in violation of the release calendar
Since releases are planned “one by one” or even “in parallel” - any delay in any stage, and, accordingly, non-release of resources usually affects both the current and not the next release through a shortage of resources.
Based on the design of the stages of release and transition between them - the greatest negative effect has a delay in the stages of development and testing. The analysis phases (“Draft”, “Scope”, “Approval”) have the opportunity to lower the content of the release by transferring unfinished applications to the next release - and this is perceived by the customer, usually easier than transferring from the approval of the content of the release.
Taking "increased commitments"
This is the main reason for the violation of the release calendar. Since the process at each stage implies that the team takes on obligations, based on the available resources - there is always a procedural opportunity to reduce the amount of delivery to meet the deadlines. However, very often - under pressure from the customer, or in pursuit of "development" (which often happens during contract development) - the team takes on "increased obligations", which are immediately reflected either in terms or quality (and most often - and on that and on the other).
As a measure, you can use a pessimistic estimate of the amount of resources when fixing the contents of the release at the stage of “Approval”. In general, the topic of “underestimating the task / reassessment of one’s own forces and how to deal with it” is very controversial. And the decision is very dependent on the organizational environment in which the team works.
Realization of "big" tasks
Quite often during the analysis it turns out that the scope of the task does not fit into the time frame of the “Work in progress” stage - the required volume cannot be developed and delivered within a single release.
If it is not possible to increase the resources of developers, there are two possible ways to solve this problem:
- splitting the original task into two or more - so that each of them is independent in terms of delivery and distribution of several releases, taking into account business priorities
- if splitting is impossible for technical or other reasons - formal transfer of the task to a more distant release, and work on a full ensemble for two or more releases
Subjectively, the first option is more preferable, since it allows you to maintain the regularity of delivery and present at least some of the functionality in the current release.
However, it is quite possible, the second option may be preferable from the point of view of loading the resources of developers.
Elimination of defects in the context of releases
The handling of incidents and the elimination of defects obviously take up the resources of the team (to a greater extent - the Developers, but sometimes Analysts). In addition, often eliminating non-critical defects that have known workarounds may have less business value than the required changes. Hence, an obvious desire to consider the tasks of eliminating defects (or providing additional services) in the general context of planning the content of a release — to do what is important.
On the other hand, the elimination of defects can be approved by the customer as an a priori most important task - thus, resources for the elimination of defects will have to be allocated as a priority.
In any case, it is necessary to take into account the presence of defects in assessing the available resources that can be allocated to the content of releases.
- As a first option, you can estimate the potential volume of defects per release and the resources spent on average per defect. Resources estimated for new change requests are reduced by this estimate.
- An alternative approach is to allocate a group of resources that are responsible only for the elimination of defects. But most likely - it is advisable only in case of a large number of serious defects.
Regardless of the approach to assessing the necessary resources, the inclusion of tasks to eliminate defects in the contents of releases can be useful in analyzing the technical dependencies of all changes that the team is working on.
Conclusion
A major advantage of the release process (especially for releases with a fixed duration) in the eyes of the customer is a pre-announced release date, usually tied to specific calendar points (for example, monthly, quarterly). This allows you to build a transparent and rhythmic process, with the expected check points (transitions between stages) and the expected results at each point. In addition, the customer is directly involved in determining the content of the release by setting priorities.
For the team supporting the product, the process provides the opportunity to realize the optimal loading of their resources, and manage the scope of work, delivering changes on time and with high quality. Also, after several completed releases, based on the collected statistics, it will be easier for the team to justify requests for additional resources in response to increasing customer requests.
Source: https://habr.com/ru/post/321664/
All Articles