This is ‘Adaptive Planning - Release and Iteration Plan’ tutorial of the PMI-ACP Certification Course offered by Simplilearn. In this tutorial, we will learn about Release Planning and Sprint Reviews.
After completing this Adaptive Planning, you will be able to:
A release plan indicates how the team intends to achieve the product vision within the project objectives and constraints identified in the project data sheet. Release plans convey critical information related to the product being developed.
They help the product owner and the team to decide the time required to create or develop a product.
They also convey the expectations, such as what is likely to be developed and in what timeframe, and serve as a guidepost towards which the project team can progress.
Note that, for new projects with no historic velocity trend, release planning is done either by comparing with similar projects and determining velocity by analogy; or running some sprints to determine the velocity, using which the future release planning is performed.
The purpose of release planning is to define the contents of a release or a specific shippable product increment.
It helps the stakeholders understand what output they can expect at the end of the release and acts as a guide for the product development. There is two key information required for release planning:
The given illustration shows the flow of activities during a release plan.
Step 1: Determine the ‘conditions of satisfaction’, which includes expectations of the product owner about the scope, schedule, quality, and costs.
Step 2: Estimate the user stories.
Step 3: Select an iteration length, which is determined by the length of the release or complexity of work.
Step 4: Estimate the velocity.
Step 5: Prioritizing the user stories.
Step 6: Select the stories and a release date based on the number of stories assumed iteration velocity and the number of iterations.
The process of release plan ends if it meets the expectations of the product owner, Otherwise, the release planning process starts again.
Suppose a team’s average historic velocity is six-story points and there are five Sprints in a release, then the capacity for the release is 30 story points. User stories in the prioritized backlog will be earmarked for various releases.
As shown in the illustration, story points pertaining to Requirement 1 to Requirement 6 in the prioritized backlog add up to 30 story points. Hence, they are earmarked to be developed as part of Release 1. This concept applies to Release 2 as well.
The given illustration demonstrates the outcome of a release planning meeting. The product backlog containing all user stories, themes, and epics, is the input for the release planning meeting. During the meeting, a selection of ‘candidate user stories’ is identified and positioned into specific release.
As illustrated on the diagram, the first two releases are well-defined, whereas the remaining releases are left blank intentionally to maintain flexibility for the changes in the project dynamics. Note that the outcome of the release planning gives a bird’s eye view, listing which requirements will get aligned with each release. Also, remember that the goal of a release plan is to set expectations for the project stakeholders.
Product Roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to important product milestones. The product roadmap is a simple list of requirements to be addressed in each release.
It is developed by the product owner in collaboration with the business stakeholders.
It helps the stakeholders understand when their requirements will be delivered.
Further, a product roadmap:
The given image showcases the different requirements aligned within Release 1, Release 2, and Release 3.
Eager to know about Release Planning? Click for the course preview!
Iteration Plan is a low-level view of the product, where the team takes a detailed look at what is required to implement a feature. They take actions only on the user stories selected for the iteration. An iteration plan can be a spreadsheet or a set of note cards, with one task written on each card. It should be published for the wider stakeholder community to showcase the transparency and get their buy-in on the overall plan.
The participants of the iteration plan meeting are the Product Owner, Analysts, Programmers, Testers, Database Engineers, and User Interface Designers. After this meeting, iteration plans are developed by the entire team along with the product owner who represents business priorities. The iteration plan identifies the themes or goals that should be achieved and positions the team to start working on the iterations.
Let us look at some examples of Iteration Planning below.
The factors to be considered while selecting iteration length are as follows:
Note that, shorter duration of iteration implies that the deadlines are approaching. This induces a sense of urgency within the project delivery team.
A sample graph that represents the average length of the iteration in Agile projects is shown. The iteration is based on a survey of Agile teams. 82 percent of the teams have selected an iteration length between one to four weeks. Scrum recommends iterations of the duration of one to four weeks. There are no defined standards on the duration of an iteration.
However, there are guidelines that can help determine the best iteration length for the project. Also the third Agile principle states “Deliver working software frequently, from every couple of weeks to a couple of months, with a preference to the shorter timescale.”
The image below shows the approach that a team may take to plan an iteration when it is aware of the velocity.
Finally, the tasks will be estimated by the person who is assigned to them.
In commitment-driven iteration planning, the team is asked to add stories to the iteration one-by-one until they cannot commit anymore.
The team starts by adjusting the priority of the features and identifies an overall iteration goal. Next, in the order of priority, they will select each story, split them into tasks, and get the tasks estimated. Once the estimates are available, the team discusses whether they can make a commitment to deliver that story collectively.
If they can, it is added to the iteration backlog and the process moves to the next story. Otherwise, the story is removed from the backlog. The team identifies if their capacity is fully utilized, which means they cannot accept any more stories, or whether there are other stories that can be considered. The iteration planning session ends when the team determines the list of stories that they can commit.
This approach is useful because it focuses on the process of the team making a commitment.
In the iteration lifecycle, each iteration follows a consistent pattern of activities, such as:
Iteration Preparation involves:
Iteration Planning involves:
Story Development includes:
Demo Preparation involves:
Demo Involves:
Retrospectives Include:
The image illustrates a three-week iteration plan.
The iteration starts with preparation on Day 1, which includes agreeing on the goals, the value to be delivered, determining the architecture, and agreeing on the process of conducting tests.
On Day 2, the team begins reviewing the stories selected for the iteration and determining the tasks and effort to complete the stories.
From Day 3, the team is focused on implementing the stories using a Test-Driven Development process by writing tests, watching them fail, writing code, developing the stories, and watching the tests pass.
On Day 14 of the Iteration, the team starts the demo preparation for the product owner and customers.
On Day 15, the development team conducts the demo of the final product to the stakeholders and gets their feedback. New requirements emerge as part of these demos, which are captured by the product owner and considered for future sprints based on its priority.
After the demo is completed, the team conducts the retrospective. This is done to review what worked well and what can be improved for the next iteration. The team can also review its velocity and update the metrics on the information radiators used in the team room.
The release plan looks forward to the release of the product while the Iteration Plan looks ahead only the length of one iteration. The differences between these are as follows:
Release Plan |
Iteration Plan |
|
|
Prioritization is the act of deciding the order in which the team should start working on the requirements. The business value associated with the requirement is the key driver to prioritization. Product owner ensures the requirements in the product backlog are prioritized and that they deliver the maximum return on investment.
However, there are other factors to be considered while prioritizing, such as the cost of delivery, cost of delay, payback frequency, and dependencies.
Cost of Delivery – This is the cost associated with developing a feature. This refers to delivering one priority requirement with a higher cost of development versus delivering a bunch of lesser priority requirements that could be developed at similar costs.
Cost of Delay – This is the time the customer has to wait in addition to the product development time. Product owner may choose to deliver one priority requirement that has a lower cost of delay in delivering a bunch of lesser priority requirements that has a higher cost of delay.
Payback Frequency – This involves determining whether the frequency of payback from the feature is daily, monthly, or yearly, and accordingly prioritize the features.
Dependencies – Some high priority feature can be developed only when the related low priority feature is developed.
Projects are undertaken with return on investment as a key factor. Therefore, it is important to determine the project cost during the early phase, which helps in aligning with the expectations. The steps to be followed to come up with an initial understanding of what can be delivered within a release or sprint are:
Determine the requirements’ size in story points or ideal time, that is, using the estimation techniques to determine the size of the requirements in story points or ideal time.
Calculate the effort required, that is, based on the team’s average availability, convert the ideal time into elapsed time, which is required to accomplish the requirements. This is done by dividing ideal time by the team’s average availability.
Convert the effort into a schedule, that is, depending on the team size and the average number of working days in a month, convert the overall elapsed time into duration by dividing the elapsed day by a number of resources and working hours.
Compute the cost of the project, that is, the overall cost of the project is determined by applying resource cost for the duration of project schedule, and considering the other loaded cost involved in running the project.
Determine the project schedule and the overall project cost using the data in the table. Using the given data, the project schedule and the overall project cost can be determined as follows:
First, determine the requirements’ size in story points or ideal time. In this example, the cumulative ideal time of the requirements adds up to 200.
Next, calculate the effort required. If the team is available for 75% of the time to work on the project deliverable, the elapsed time is 200 divided by 75%, which is 267 days.
Next, convert the effort into the schedule. If the team consists of five resources, each working for eight hours a day, then the project schedule would be 267 divided by 40, assuming that five resources would work for 8 hours per day, is approximately 7 days. Lastly, compute the cost of the project. If the per day resource cost is $250 and another expense is $500, the overall project cost is $250 multiplied by 7 plus $500, which is $2,250.
Let’s understand the cone of uncertainty.
During the early stages of the project, many details are unclear, such as the expectation of the stakeholders, nature of the software being built, technology to be used, resource skills needed, number of resources required, project plans, and risks. To handle this, the team comes up with a Rough Order of Magnitude or ROM estimate during the early stages of the project, wherein the range can go up by four times.
However, as the project progresses and the project dynamics are understood, the estimates are constantly refined through the grooming session. Through constant grooming sessions, estimates start to become accurate and the range starts to narrow down. This is graphically represented by the ‘Cone of Uncertainty.’ The Cone of Uncertainty, which showcases how the accuracy of estimates improve across various stages, is illustrated here.
During the initial stages of the project, when the availability of project details is limited, the project estimates can vary by as much as four times. As the project progresses and as the team gains a better understanding of the application being developed, this range will slowly narrow down. This is also depicted in the illustration.
In Agile Projects, the Cone of Uncertainty extends over the entire project, including each sprint of the project. Although the team would use the velocity from previous iterations as a reference to plan the current sprint, the project dynamics associated with each sprint will make the outcome unpredictable.
The risk associated with uncertainty within the sprint can be addressed through addressing high-risk features early in the release, frequent code check-in, frequent cycles of automated testing, and daily review of the evolving solution with the product owner to avoid any surprises. Note that it is recommended to state the estimates in ranges rather than absolute value. This offers necessary leverage to handle uncertainty during sprint and release planning.
The velocity of the team is expected to vary the most during the initial stages of the project. As the team gains a better understanding of the project dynamics, velocity would gradually improve. However, a steady increase cannot be assured. Some of the key reasons are:
The diagram illustrates the velocity variations, where there is a difference between the projected velocity and the actual velocity. The dotted line represents the projected velocity trend, while the blue line represents the actual velocity trend. Note that, over a period, velocity would settle down and this average velocity should be used to determine upcoming release and iteration capacities. This ensures that the velocity variation is kept to a bare minimum.
Sprint Reviews are timeboxed sessions conducted towards the end of an iteration, where the evolving solution is showcased to the stakeholders and their feedback is sought. The session is normally scheduled towards the end of the sprint. It is timeboxed to four hours for a monthly sprint and proportionately less for a shorter time period.
Further, the sprint review sessions are attended by the entire team consisting of a development team, product owner, Scrum Master, and the business stakeholders. These sprint review sessions are used by the team to showcase the product through live sessions, WebJoin, recordings, or snapshots.
Conducting regular sprint review sessions helps to facilitate the following:
Sprint review is an important meeting and is necessary to conduct towards the end of the sprint. In projects with two-week sprint, failing to perform a sprint review may put the project schedule behind by one month. This is because the requirement developed might not meet the stakeholders’ expectation.
This is also because the requirements selected for the upcoming sprint might not be aligned with stakeholders’ expectation. This results in project falling behind by a sprint or 15 days.
Learn more about Sprint Reviews. Click here!
Sprint Retrospections are the timeboxed sessions conducted towards the end of an iteration, to understand how the team can improve the ‘Way they Work’. Like sprint reviews, these sessions are also normally scheduled towards the end of the sprint. They are timeboxed to three hours for a monthly sprint and proportionately less for a shorter time period, and attended by the entire Scrum team consisting of the Development team, product owner, and ScrumMaster.
In Sprint Retrospections, the team acknowledges the areas in which they have done well and the areas that need improvement. Feedback from retrospective sessions is critical to implement continuous improvement strategies and maximize the value being delivered by the project.
The Scrum team meets regularly during the sprints to groom the backlog. Grooming or refinement is a way of progressively elaborating the backlog, so it remains current and reflects the needs of the stakeholders. Though these are not timeboxed or scheduled meetings, product owner has to ensure such meetings happen at regular interval.
These meetings help in adding new user stories to the product backlog, removing user stories which are not relevant, estimating newly added user stories, re-estimating the user stories based on the newly identified information, prioritizing or re-prioritizing the user stories, and splitting epics into smaller user stories. As a thumb rule, the team needs to dedicate 10% of their time towards backlog grooming.
Some points to remember about backlog grooming are:
The product backlog being refined and updated with evolving details, as part of the grooming session, is illustrated on the given image. The table below shows the input, which includes product backlog prior to the grooming session. The table on the right shows the prioritized backlog after the grooming session.
It indicates that the product backlog has been revamped. Now, the priority of the backlog items and the associated story points have changed, and the backlog items are further broken down. The grooming session provides an opportunity to review the product roadmap regularly and confirms if they require any modification.
Agile projects are undertaken in a competitive and dynamic environment. Hence, the plan must be constantly reviewed. In Agile projects, mid-course corrections must be made to ensure the project is still viable and delivers the business benefit. More time is required for planning in Agile projects. However, the planning activities are spread throughout the project.
Various planning meetings throughout the project provide an opportunity to perform mid-course corrections. A few factors that impact the project and hence need to be constantly monitored are:
Mid-course corrections help organizations to reflect upon changes to the requirements, shifting priorities, delivery experience, stakeholders’ feedback, and market trends. These, in turn, adjust the project parameters, such as project scope, estimates, delivery schedule, and cost.
Mid-course correction ensures that the product roadmap is adjusted to reflect the actual performance and manage stakeholder expectations. It also ensures that the estimated completion time is maintained. The given image showcases the deviations from the original plan, which is likely to happen in an Agile project. The blue line represents the original plan and the green line represents the actuals.
To reduce such deviations, it is recommended to proactively perform mid-course adjustments within the project timelines. Note that, as the knowledge increases, leaders perform mid-course corrections to guide the project towards enhanced goal.
‘Inspect and Adapt’ is the key principle used in Agile projects, wherein the overall project plan is refined throughout, by incorporating the lessons learned from the retrospective findings. This mid-course correction acts as a product feedback loop, thereby enabling progressive elaboration of requirements and other project details.
As illustrated in the image, the details are finely grained in the Release 1 and all relevant information needed to convert the requirement into solution is made available. However, details for the Release 2 are coarsely grained and the information is being progressively elaborated through the grooming session to gain a better understanding. This is done based on the product feedback loop. Further, in Release 3, only the high-level details exist.
The project team tracks its progress against a release plan by updating a release burndown chart at the end of each iteration. The graph shows a hypothetical burndown chart for a project across several iterations:
The rate at which the team is completing work is indicated by a thick blue line connecting the points. Each point indicates the amount of work remaining in the story points at the start of the iteration. Note that, when the graph reaches zero, there are no more story points in the project and it is ready for release.
Working on Agile projects can be stressful sometimes, considering the fact that there is a deadline every week. Agile games serve as an excellent tool to move out of the regular delivery focus and promote innovative thought process in people.
Agile Games, also referred to as ‘Collaborative’ or ‘Innovative Games’ help understand complex problems, discuss the potential solution, and come to a quick consensus. A few common Agile games are:
Let us summarize the topics covered in this Adaptive Planning tutorial
This concludes ‘Adaptive Planning - Release and Iteration Plan’ tutorial. The next domain is ‘Problem Detection and Resolution: Fishbone Diagram.’
Name | Date | Place | |
---|---|---|---|
PMI-ACP® Certification | 6 Feb -27 Feb 2021, Weekend batch | Your City | View Details |
A Simplilearn representative will get back to you in one business day.