Adaptive Planning - Part 2 Tutorial

Hello and welcome to Domain V—Adaptive Planning of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

After completing this lesson, you will be able to: • Explain Release Plan • Describe Iteration Plan • List the steps to determine the initial schedule and cost range estimates • Describe the Cone of Uncertainty • Define Sprint Reviews and Retrospections • Discuss mid-course corrections • List the commonly used Agile games

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 are two key information required for release planning: 1. Average historic velocity of the team 2. Number of Sprints within a release

The given illustration shows the flow of activities during a release plan. • The first step is to determine the ‘conditions of satisfaction’, which includes expectations of product owner about the scope, schedule, quality, and costs. • The second step is to estimate the user stories. • The next step is to select an iteration length, which is determined by the length of the release or complexity of work. • The following step is to estimate the velocity. • Prioritizing the user stories is the next step, and • The last step is to select the stories and a release date based on the number of stories, assumed iteration velocity, and number of iterations. The process of release plan ends if it meets the expectations of the product owner. Otherwise, the release plan 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 to 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’ are 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 to 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. 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 forms an integral part of any product strategy; provides the framework to plan changes; manages the effects of changes on the product; and represents the long term product vision or goal of the product. The given image showcases the different requirements aligned within Release 1, Release 2, and Release 3.

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 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.

The factors to be considered while selecting iteration length are as follows: The length of the current release, for instance, a three month release would not get sufficient feedback opportunities if iterations are four weeks long. The amount of uncertainty, that is, projects with high degree of novelty or complexity will require longer iterations as there will be more technical debt, if the underlying architecture changes. The ease of getting feedback, that is, a convenient schedule can be selected to support the project sponsors and the key stakeholders, if they are unable to participate in weekly iteration demos. The duration in which priorities can remain unchanged, that is, if business priorities shift frequently, shorter iterations can be recommended. Willingness to go without feedback, that is, when the team has a thorough understanding of the requirements, the risk associated with delayed feedback would be less. The overhead of iteration, that is, iterations have overhead in the form of planning, scheduling, preparing a final build, creating demo scripts, and manual activities that are difficult to automate. 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 couple of months, with a preference to the shorter timescale.”

The graphic on the screen shows the approach that a team may take to plan an iteration, when it is aware of the velocity. The team starts with adjusting the priority of the features. Remember, this is an ongoing activity and should be performed prior to each sprint. Next, the team determines its target velocity based on the past performance and historical data. Note that the velocity may vary based on different factors. This technique is used to determine a rough duration of the project. The team will assess its ability to commit to the deliverables of an iteration during the iteration planning meeting. Next, the team will identify a goal for the iteration based on the input from the product owner. Further, based on the selected goal, they would select as many stories aligned with the goal as they can accommodate within the target velocity. Next, these user stories will be split into tasks. 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 with 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, • Iteration Planning, • Story Development, • Demo Preparation, • Demo, and • Retrospectives. Iteration preparation involves setting the goals, identifying the value, assessing the architecture, and agreeing on the tests. Iteration planning involves reviewing the stories, planning the tasks, forecasting the work, and working the plan. Story development includes building tests and failing them, developing stories, passing the tests, and conducting daily stand-up meetings. Demo preparation involves comparing what is done to what was planned, ensuring everything works, and developing a demo script. Further, demo involves demonstrating the solution to the stakeholders, getting their feedback, and capturing new requirements to be considered for future sprints. Lastly, retrospectives include reviewing the plan, checking the numbers, getting feedback, and improving the document. To view a graphical illustration of the iteration lifecycle, click the ‘Illustration’ button given on the screen. 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 through 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 is based on user stories, whereas the iteration plan is based on tasks. • The planning horizon of a release plan is three to nine months, whereas the planning horizon of an iteration plan is one to four weeks. • Estimations are done in story points or ideal days in a release plan, whereas they are done in ideal hours in an iteration plan. Note that, ensuring the transparency of release and iteration planning activities improves stakeholder participation. It also increases the commitment level and reduces uncertainty.

Prioritization is the act of deciding the order in which the team should start working on the requirements. Business value associated with 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 of investment. However, there are other factors to be considered while prioritizing, such as cost of delivery, cost of delay, payback frequency, and dependencies. Click each tab to know more. Cost of Delivery – This is the cost associated with developing a feature. This refers to delivering one priority requirement with 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 over 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 team’s average availability. Convert the effort into 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 number of resources and working hours. Compute the cost of the project, that is, 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. Click the ‘Answer’ button to know more. 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, 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 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 other expense is $500, the overall project cost is $250 multiplied by 7 plus $500, which is $2,250.

During the early stages of the project, many details are unclear, such as 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 start 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 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 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.

Velocity of the team is expected to vary the most during the initial stages of the project. As the team gains better understanding of the project dynamics, velocity would gradually improve. However, a steady increase cannot be assured. Some of the key reasons are: • More code or functionalities need to be altered to ensure the existing functionality is not impacted, • More code needs to be refactored, and • Complexity of functionality increase. 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 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 shorter time period. Further, the sprint review sessions are attended by the entire team consisting of development team, product owner, ScrumMaster, 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 reviews are a perfect way of ensuring if the product is evolving according to the needs of the stakeholders. Any feedback or escalations are proactively noted by the product owner or ScrumMaster and addressed in the upcoming sprints or releases. Also, the prioritized backlog will be showcased to the stakeholders to get a view if it aligned with their expectation. Further, sprint reviews help in progressively elaborating the future project plan.

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.

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 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 are 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: • Grooming session provides the perfect opportunity to revise the estimate range, as the team gains better understanding of the overall solution. • The stakeholder expectations are managed by keeping the product backlog updated with latest information. • As a best practice, the prioritized and updated product backlog should be reviewed with the stakeholders as part of the Sprint Review meetings to ensure there is a common understanding of the product development roadmap and the expected deliverables in upcoming sprints. • Feedback received from maintenance and operational issues needs to be factored, and if needed, new requirements must be added to the product backlog, and • The current defects identified are analyzed in the grooming session and plans to fix them are discussed.

The product backlog being refined and updated with evolving details, as part of the grooming session, is illustrated on the given image. The table on the left 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 provides an opportunity to perform mid-course corrections. A few factors that impact the project and hence need to be constantly monitored are: • Risks, • Resource availability, • Ad hoc change requests, • Project size, • Performance fine tuning, • Technological changes, • Stakeholder expectations and feedbacks, • Emerging trends, • Team’s velocity variations, and • Maintenance and operations demand. 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 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 horizontal axis shows the iterations, and the vertical axis shows the number of story points remaining in the project. 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: • Remember the Future • Product Box • Prune the Product Tree • Speed Boat • Buy a FeatureSpider Web, and • Dot Voting

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Let us summarize the topics covered in this lesson: ? 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. ? An Iteration Plan is a low-level view of the product, where the team takes a detailed look at what is necessary to implement the feature, and actions are taken only on the user stories selected for the iteration. ? Product Roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to important product milestones. ? Factors like cost of delivery, cost of delay, and payback frequency should be considered while prioritizing the requirements. ? In Agile projects, the Cone of Uncertainty extends over the entire project, and also into each Sprint of the project. ? Sprint Reviews are timeboxed sessions conducted towards the end of the iteration, where the evolving solution is showcased to the stakeholders and their feedback is sought. ? The Scrum team, including the Product Owner, ScrumMaster, and the Development Team, meet regularly during the Sprints to groom the backlog. ? The project plan must be constantly reviewed; and if needed, mid-course corrections must be made to ensure the project is still viable and delivers the business benefit. ? ‘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. ? Agile games serve as an excellent tool to move out of the regular delivery focus and promote innovative thought process in people.

This concludes ‘Domain V—Adaptive Planning.’ The next domain is ‘Problem Detection and Resolution.’

Hello and welcome to Domain V—Adaptive Planning of the PMI-ACP Certification course offered by Simplilearn. This is the second part of this domain.

After completing this lesson, you will be able to: • Explain Release Plan • Describe Iteration Plan • List the steps to determine the initial schedule and cost range estimates • Describe the Cone of Uncertainty • Define Sprint Reviews and Retrospections • Discuss mid-course corrections • List the commonly used Agile games

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 are two key information required for release planning: 1. Average historic velocity of the team 2. Number of Sprints within a release

The given illustration shows the flow of activities during a release plan. • The first step is to determine the ‘conditions of satisfaction’, which includes expectations of product owner about the scope, schedule, quality, and costs. • The second step is to estimate the user stories. • The next step is to select an iteration length, which is determined by the length of the release or complexity of work. • The following step is to estimate the velocity. • Prioritizing the user stories is the next step, and • The last step is to select the stories and a release date based on the number of stories, assumed iteration velocity, and number of iterations. The process of release plan ends if it meets the expectations of the product owner. Otherwise, the release plan 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 to 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’ are 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 to 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. 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 forms an integral part of any product strategy; provides the framework to plan changes; manages the effects of changes on the product; and represents the long term product vision or goal of the product. The given image showcases the different requirements aligned within Release 1, Release 2, and Release 3.

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 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.

The factors to be considered while selecting iteration length are as follows: The length of the current release, for instance, a three month release would not get sufficient feedback opportunities if iterations are four weeks long. The amount of uncertainty, that is, projects with high degree of novelty or complexity will require longer iterations as there will be more technical debt, if the underlying architecture changes. The ease of getting feedback, that is, a convenient schedule can be selected to support the project sponsors and the key stakeholders, if they are unable to participate in weekly iteration demos. The duration in which priorities can remain unchanged, that is, if business priorities shift frequently, shorter iterations can be recommended. Willingness to go without feedback, that is, when the team has a thorough understanding of the requirements, the risk associated with delayed feedback would be less. The overhead of iteration, that is, iterations have overhead in the form of planning, scheduling, preparing a final build, creating demo scripts, and manual activities that are difficult to automate. 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 couple of months, with a preference to the shorter timescale.”

The graphic on the screen shows the approach that a team may take to plan an iteration, when it is aware of the velocity. The team starts with adjusting the priority of the features. Remember, this is an ongoing activity and should be performed prior to each sprint. Next, the team determines its target velocity based on the past performance and historical data. Note that the velocity may vary based on different factors. This technique is used to determine a rough duration of the project. The team will assess its ability to commit to the deliverables of an iteration during the iteration planning meeting. Next, the team will identify a goal for the iteration based on the input from the product owner. Further, based on the selected goal, they would select as many stories aligned with the goal as they can accommodate within the target velocity. Next, these user stories will be split into tasks. 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 with 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, • Iteration Planning, • Story Development, • Demo Preparation, • Demo, and • Retrospectives. Iteration preparation involves setting the goals, identifying the value, assessing the architecture, and agreeing on the tests. Iteration planning involves reviewing the stories, planning the tasks, forecasting the work, and working the plan. Story development includes building tests and failing them, developing stories, passing the tests, and conducting daily stand-up meetings. Demo preparation involves comparing what is done to what was planned, ensuring everything works, and developing a demo script. Further, demo involves demonstrating the solution to the stakeholders, getting their feedback, and capturing new requirements to be considered for future sprints. Lastly, retrospectives include reviewing the plan, checking the numbers, getting feedback, and improving the document. To view a graphical illustration of the iteration lifecycle, click the ‘Illustration’ button given on the screen. 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 through 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 is based on user stories, whereas the iteration plan is based on tasks. • The planning horizon of a release plan is three to nine months, whereas the planning horizon of an iteration plan is one to four weeks. • Estimations are done in story points or ideal days in a release plan, whereas they are done in ideal hours in an iteration plan. Note that, ensuring the transparency of release and iteration planning activities improves stakeholder participation. It also increases the commitment level and reduces uncertainty.

Prioritization is the act of deciding the order in which the team should start working on the requirements. Business value associated with 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 of investment. However, there are other factors to be considered while prioritizing, such as cost of delivery, cost of delay, payback frequency, and dependencies. Click each tab to know more. Cost of Delivery – This is the cost associated with developing a feature. This refers to delivering one priority requirement with 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 over 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 team’s average availability. Convert the effort into 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 number of resources and working hours. Compute the cost of the project, that is, 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. Click the ‘Answer’ button to know more. 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, 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 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 other expense is $500, the overall project cost is $250 multiplied by 7 plus $500, which is $2,250.

During the early stages of the project, many details are unclear, such as 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 start 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 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 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.

Velocity of the team is expected to vary the most during the initial stages of the project. As the team gains better understanding of the project dynamics, velocity would gradually improve. However, a steady increase cannot be assured. Some of the key reasons are: • More code or functionalities need to be altered to ensure the existing functionality is not impacted, • More code needs to be refactored, and • Complexity of functionality increase. 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 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 shorter time period. Further, the sprint review sessions are attended by the entire team consisting of development team, product owner, ScrumMaster, 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 reviews are a perfect way of ensuring if the product is evolving according to the needs of the stakeholders. Any feedback or escalations are proactively noted by the product owner or ScrumMaster and addressed in the upcoming sprints or releases. Also, the prioritized backlog will be showcased to the stakeholders to get a view if it aligned with their expectation. Further, sprint reviews help in progressively elaborating the future project plan.

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.

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 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 are 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: • Grooming session provides the perfect opportunity to revise the estimate range, as the team gains better understanding of the overall solution. • The stakeholder expectations are managed by keeping the product backlog updated with latest information. • As a best practice, the prioritized and updated product backlog should be reviewed with the stakeholders as part of the Sprint Review meetings to ensure there is a common understanding of the product development roadmap and the expected deliverables in upcoming sprints. • Feedback received from maintenance and operational issues needs to be factored, and if needed, new requirements must be added to the product backlog, and • The current defects identified are analyzed in the grooming session and plans to fix them are discussed.

The product backlog being refined and updated with evolving details, as part of the grooming session, is illustrated on the given image. The table on the left 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 provides an opportunity to perform mid-course corrections. A few factors that impact the project and hence need to be constantly monitored are: • Risks, • Resource availability, • Ad hoc change requests, • Project size, • Performance fine tuning, • Technological changes, • Stakeholder expectations and feedbacks, • Emerging trends, • Team’s velocity variations, and • Maintenance and operations demand. 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 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 horizontal axis shows the iterations, and the vertical axis shows the number of story points remaining in the project. 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: • Remember the Future • Product Box • Prune the Product Tree • Speed Boat • Buy a FeatureSpider Web, and • Dot Voting

Following is the quiz section to check your understanding of the lesson. Select the correct answer and click Submit to see the feedback.

Let us summarize the topics covered in this lesson: ? 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. ? An Iteration Plan is a low-level view of the product, where the team takes a detailed look at what is necessary to implement the feature, and actions are taken only on the user stories selected for the iteration. ? Product Roadmap is a planned approach that helps with strategic project planning and communication of that plan with respect to important product milestones. ? Factors like cost of delivery, cost of delay, and payback frequency should be considered while prioritizing the requirements. ? In Agile projects, the Cone of Uncertainty extends over the entire project, and also into each Sprint of the project. ? Sprint Reviews are timeboxed sessions conducted towards the end of the iteration, where the evolving solution is showcased to the stakeholders and their feedback is sought. ? The Scrum team, including the Product Owner, ScrumMaster, and the Development Team, meet regularly during the Sprints to groom the backlog. ? The project plan must be constantly reviewed; and if needed, mid-course corrections must be made to ensure the project is still viable and delivers the business benefit. ? ‘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. ? Agile games serve as an excellent tool to move out of the regular delivery focus and promote innovative thought process in people.

This concludes ‘Domain V—Adaptive Planning.’ The next domain is ‘Problem Detection and Resolution.’