Importance of Adaptive Planning in Agile
- 1. Importance of Adaptive Planning By Sangeetha Siddhantam PMP, PMI-ACP
- 2. Organizations encourage adaptive planning for projects. Planning to re- plan is a successful way to achieve project goals. Changes are inevitable in projects and responding to these changes is important. Accommodating changing requirements throughout the development process is a key principle of agile. Adaptive planning enables us to manage these changes effectively. Doing necessary adaptive planning not only minimizes waste but delivers maximum business value. As a result of adaptive planning, organizations are not only able to continuously increase their business value, reduce risk, adapt to changing requirements but also achieve high visibility to project progress.
- 3. Let’s quickly glance at differences between agile and non-agile (traditional) planning. While traditional planning is a linear approach, agile is iterative and a team-based approach. Upfront planning is emphasized in traditional planning. This can lead to problems as we gradually progress in projects. Whereas in agile, planning is iterative and progressive. To reflect planning and risks associated with both agile and non-agile methodologies, Boehm came up with a term “planning sweet spot”. To avoid losses incurred due to inadequate planning and market share erosion, Boehm suggested that we aim for “sweet spot planning”, by planning just enough to minimize any risk and rework. Agile teams strive for customer feedback by demos and working prototypes. If they fail to get customer acceptance, they re-plan their strategy midcourse by making adjustments to the iteration till they get business approval. From this, we can say that midcourse adjustments are normal in agile.
- 4. Principles of Agile Planning
- 5. There are 9 high level principles for agile planning: • Agile focuses on planning at multiple levels. The amount of details addressed at each level results in delivering continuously a high value product. • For a project to be successful , two-way communication is very important. Both team members and customers should be engaged in planning. Customers should be available for the trade-off, demos, and feedback on the deliverables. • Being transparent is a key aspect of Agile. Frequent demonstration of progress keeps stakeholders updated on project status. • Uncertainty is very high in large or complex projects. Prescribing one process to the entire project does not fit project’s purpose as teams and requirements are different at different phases of the project. Agile tailors the process to fit different natures of the project by minimizing uncertainties, risk and rework. • Agile backlog makes release and iteration planning easier. The product owner should see how changes influence backlog and release plans. Depending on projects priorities, plans should be be updated continuously. • Estimating a project should not be limited to the schedule and cost of the project. Always look at other risks such as the velocity trends of the team, their availability, any distractions, diversions that can occur inevitably. Also factor in the availability of skilled resources in due course of the project. Not having skilled resources when required can throw the entire project off the track. • Use estimate ranges to factor-in uncertainties. • Project projection on completion data should be based on the actual or real progress of the project rather than a plan based on theory. • While estimating, factor in all the possibilities of the resources ideal time, unproductive time, and their absences so that the project can handle unforeseen circumstances.
- 6. Agile Discovery in Adaptive Planning Agile Discovery in Adaptive Planning: Contrast to traditional project planning agile project plans evolve over a period of time. This evolution of agile project plan is referred as agile discovery. Agile discovery is the process of gathering information on what the customer requires and making informed recommendations that are critical at the very beginning of project. Progressive elaboration in action New information incorporated into project plans and continuous update of project plans as we progress into the project is called progressive elaboration. As the project progress the details not only become more specific and accurate, but also the changes are updated in each successive iterations. The key benefit of Progressive Elaboration in Agile, is that teams spend maximum amount of time on high-priority features and minimum amount of time on low-priority features. Let’s see progressive elaboration in action: 1. Fractal leaf pattern Throughout the project we are continuously identifying new requirements, grouping them and prioritizing their features accordingly, and they are refined as more details become available similar to a fractal leaf pattern. The ultimate goal is to deliver a highly detailed product by end of the project. 2. Coarse grained requirement In agile, detailed planning is never encouraged. The requirements are coarsely grained and refined as the project progresses so that changes are incorporated continuously resulting in reducing risk, increasing productivity and getting early feedback from customers. Rolling wave planning: Progressive elaboration should not be confused with rolling wave planning. In rolling wave planning, detailed project planning is done for high priority features, items or activities and only high level planning for low priority items that are in future.
- 7. Process of Assessing: Value-based Analysis & Value-based Decomposition
- 8. Value-based analysis is a management strategy used to determine changes in value with concerning to quality and cost. Lately, organizations want to produce products quickly with less cost than delivering a one-time high- value product. By releasing a low-value product, we can see the product behavior and determine how we can strengthen the product by its competitiveness in the market. Value-based decomposition is an extension of value-based analysis. In this process, a low-value product is sliced further keeping in mind to produce a value-driven product to the customer. Value-based decomposition ensures that customer is satisfied at all levels.
- 9. Agile Concept of Timeboxing
- 10. Timebox: A timebox refers to a period during which the team agrees to complete an item or activity of a project. Any uncompleted work is moved to the next period or into another timebox and waits for subsequent iterations. The goal of timeboxing is to limit the time dedicated to a particular item or activity. In the previous slide we discussed value-based analysis, where at times a high-value item is dependent on a low-value item. If we can manage to deliver low-value items on time, then delivering high-business-value items is assured. Timeboxing focuses on delivering low-value items frequently and tracks how the project is progressing in actual. You can also refer to my previous Slideshare “Introduction to Agile” for timeboxing in Scrum and the DSDM prioritization technique Moscow. While delivering the low-level items, the “must have” items also need to be identified. The delivery process can be continuously reassessed by prioritizing the low-level items with Moscow and by timeboxing the item. Timeboxing was developed by DSDM consortium by its founders in 1990. Agile project management traded the traditional triangle of constraints for the inverted triangle model. By keeping time and cost fixed, the team can adjust the scope through multiple iterations. This is another variation of time-boxing.
- 11. Estimate Ranges in Agile
- 12. For any knowledge work projects, uncertainty and complexity are very high, making the estimation process difficult. Similar to traditional estimation, agile can use either expert knowledge based (heuristic) or parametric estimates in which calculations are based on numbers and complexity of user stories. When estimating in agile, the key things to consider are why and what is being estimated, and who are involved in the estimation process. Close range estimates are used for smaller sized projects with certainty. Wide range estimates are used for larger complex projects with uncertainty. Barry Boehm’s concept of “Cone of Uncertainty” describes that uncertainty is very high during the initial phase of the project, and decreases gradually as the project progresses. Similar to this phenomenon, estimate ranges are initially very broad due to uncertainty and narrows down as specifications and scope become clear through the progression of the project. In estimating ranges for the project, the following three types of resources are involved: The product owner gives the requirements to the team. The team comes up with ideal time estimates to complete the project uninterrupted while removing all distractions and diversions. The agile coach is involved in facilitating the meetings, and is also one of the key members involved in estimating.
- 13. Basic structure for an Agile Requirements: Feature, User Stories, and Task
- 14. From my experience as a Project Manager, it is significant to know how and why sizing affects projects. Accurate estimation of the size and scope will lead to effective planning and successful execution of the project. A large and complex project can be sliced into smaller parts or, in other words, decomposed. The smaller/decomposed parts get refined and reassessed till they become the actual requirement. The basic structure of agile requirements would include: • Features • User stories (will be discussed in detail later on) • Tasks Features would have business value and priorities. User stories provide short and simple description of features to be built in the project by agile teams and are typically written on index cards. (Ah ha now we have index cards so what are we going to do with them? Interestingly there are three things known as three c’s that user stories capture.)
- 15. The Three C’s of user stories: Card- Team members, along with the help of the product owner, write a detailed, single, compact sentence on these cards. These stories are written so that they can be tested and accepted by the customer. The product owner prioritizes user stories in the backlog using team inputs. Conversation- The agile manifesto encourages face-to-face conversations, during which ideas and opinions are exchanged during the story writing process. Confirmation- The customer approves that the user story has been completed according to the agreed acceptance criteria set beforehand. Since we are diving into user stories, I would like to share some key characteristics of user stories. Bill Wakes created a mnemonic called INVEST. Let us break down each component here. I- Independent User stories are created independently and selected on merit. N- Negotiable Team should be able to negotiate user stories with the product owner. V-Valuable User stories should have value or benefit to the customer. E- Estimable User stories should be good enough to be estimated so that they are properly prioritized. S-Small User stories that are small are easy for estimating and testing. T-Testable Acceptance tests are written on the back of user story cards. Writing the test early helps to know if the goals are met.
- 16. Since we are talking about user stories, Lets quickly go over user story backlogs (also known as product backlog) and refining backlogs (also know as backlog grooming). A user story backlog or product backlog is a list of user stories that need to be prioritized and completed in the project after user stories are created. The product owner is responsible for creating and maintaining the product backlog. According to the principals behind the agile manifesto, changes are welcome even late into the project. As the project progresses, product backlog is continuously updated with new information for the new and changed requirements. The process of re-organization and re-prioritization of the backlog is called as refining or grooming the backlog. During backlog refining, either new stories are added and prioritized, or some of the existing stories are removed, or existing user stories are sliced into smaller chunks.
- 17. I get it, we talked enough about user stories. BUT, please remember we are still discussing the basic Agile features of Task. Task- As the user stories are decomposed, the team works on completing these stories. When teams are working on a task they are working with specific scope with a specific timeframe. This is one of the reasons why tasks often follow the SMART acronym : S-Specific The task should be simple and specific, making sure everyone involved understands what needs to be accomplished in each iteration. M-Measurable The team must determine how a completed task is measured; in other words, when the task can be determined as “done”. A-Achievable Task is realistic and achievable. R-Relevant Every task must be relevant and contribute to the story. T-Time-boxed Task should be limited to a specific duration, or timebox.
- 18. Guidelines for Estimating User Stories
- 19. Lets quickly go through story points and relative sizing before moving further into guidelines for estimating user stories. Story Point- The assignment of a number representing the effort to a user story depending on the difficulty level of the respective user story. Relative Sizing- Agile teams always compare the user stories they want to estimate with some previously estimated stories (known as triangulation). To estimate more effectively, teams rely on relative sizing. Relative sizing allows teams to make useful estimates to predict the approximate time it takes for each user story. Guidelines 1. The team should create and own the definition of story points 2. Story point estimates should be all-inclusive (include risk, velocity, and complexity) 3. Story point sizes should be relative 4. When disaggregating estimates, the totals does not have to match Story point estimating typically uses the Fibonacci sequence, the sequence of adding the previous two numbers together; e.g. 0+1=1, 1+1=2, 1+2=3, 2+3=5, etc.
- 20. High-Level Estimating Tools Affinity Estimating T-Shirt Sizing Story Maps Road Maps
- 21. Affinity estimating- A technique where similar stories are grouped and are assigned either a value or number creating a scale. T-shirt sizing- User stories are compared and broken into different sizes like extra large, large, small and extra small. T-shirt estimating is done during the initial stages of the project, updated continuously throughout the project and practices relative sizing (refer to a previous slide for relative sizing). Story maps- A story map is a high-level agile planning tool with an end to end view. A user story map is a collaborative practice that guides the agile team in creating product backlog. Story maps not only are an effective and useful tool for capturing requirements but also makes it easier to work on user stories as the teams are on the same page right from the initial project stage. Because of high visualization, teams can identify any missing puzzles in the project. Story maps help avoid waste and prioritize what minimally needs to be built. Story maps also improve communication not only within the teams, stakeholders, customers but also with everyone involved in the project. Product Roadmap- Is a high-level effective tool to show the evolution of the product as the project progresses. Product roadmap provides stakeholders an idea of how the product would look and how much it would cost to develop the product. Typically product roadmap consists of one or more story maps, showing what will be delivered in each release.
- 22. Tools for estimating user stories • Wide band Delphi • Planning Poker
- 23. Wide band Delphi- A group of experts participating anonymously submitting estimates is known as Wide band Delphi. Wideband Delphi is a consensus based estimation technique for estimating effort. It reflects agile values because it is iterative, adaptive and collaborative in nature. Planning poker- Like Wideband Delphi, planning poker is also a consensus based estimating tool. Planning poker provides more accurate estimates than any other techniques. Planning poker uses playing cards where values are based on the Fibonacci sequence. These values can be user story points or any unit that the team wants to estimate. Product owner and team discuss what needs to be estimated and when the facilitator reads out a problem aloud all the team members puts a card face down on the table. Cards are revealed at the same time and the team discusses the difference. They continue to play this game till everyone reaches consensus on reasonable estimates so the project can keep moving forward.
- 24. Release plan Different types of iteration: Iteration 0 Development iterations Iteration H, (also known as hardening spirt or release sprint)
- 25. A quick synopsis of Release planning Release plan is a design (e.g. high level draft) for the entire project. Release plan usually has more than one release in a year depending on the complexity of the project. Release plan is a plan that is created to deliver completed valuable product incrementally. Release plans in agile projects have fixed time and each release typically includes multiple iterations. Since release plan is a high level design, iteration plans are created for capture details of he plan. During Iteration planning, the team selects the user stories with high priority to be developed in each iteration. Each iteration is typically lasts from a week to three weeks depending on the velocity of the team. Release plan is frequently refined. Remember? Agile can handle changes late in the development.
- 26. Different types of Iterations Iteration 0- Iteration 0 in general is about ensuring that we have all the necessary things for the project to start. Iteration 0 is short and outlines the deliverables. During Iteration 0, the team creates its first wireframes, the requirements are in a preliminary stage, and the team discusses requirements internally, and with the intended users. Development Iterations- Development iterations enable slicing of large requirements into smaller chunks to continuously and frequently deliver a high value driven product. One of the key advantages of multiple iterations is, once the iteration work is delivered with acceptance from everyone including customer, stakeholders will not be revisited. Iteration H (also known as hardening spirt or release sprint)- The iteration before release, where team focuses on testing and repairing any defects that they find during the development iterations is known as Iteration H (also known as hardening spirt or release sprint). In other words, this is a wrap-up iteration ensuring when the product is released it will go through all additional testing and is ready to be launched successfully.
- 27. Spikes: • Architectural • Risk based • Fast failure
- 28. Spikes- So far we know that agile includes many activities that are time-boxed. Activities that involve researching a time-boxed effort of a particular item and any risk involved with it or any other details that would be useful in making a successful high-value deliverable is known as a spike. It sets a stage for initial development effort and is used widely to investigate any issues at any given time. We now know that spike is a research activity. Time-boxed effort where the team hopes that the research activity done is good enough for the project approach is known as an architectural spike. The deliverable at the end of an architectural spike is knowledge gained and preserved either as a document or a presentation. The time-boxed research activity conducted to either reduce or eliminate risk is known as risk based spike. These spikes are used to test unfamiliarity before proceeding with the development. Fast failure- During architectural spike or risk-based spike, it is proven that the approach taken is not successful. This is known as fast failure. Agile encourages failing fast because it gives a chance to see where the errors occurred and how not to repeat them again. Like the saying goes “failure is one step closure to success”, by failing fast we learn fast not to repeat the same mistake.
- 29. • High Level Planning (Visioning) • Release Planning • Iteration Planning
- 30. Planning with Agile narrows down to three simple questions: What, When and How? High-level planning: Every product that needs to be developed needs a vision. High-level planning takes place before the first release of the project and involves product owner, sponsor, a key member of the delivery team and stakeholders roughly estimating the project by sizing and identifying the product features and user stories. High-level planning removes uncertainties and provides an updated backlog of user stories and how to respond to risk. It also provides relative estimates of each user story, deliverables and tentative dates for release planning. Release planning is a collaborative effort of everyone (including product owner, scrum master, stakeholders, and team) involved in the project understanding and committing to deliver the agreed release by the agreed date. The purpose of release planning is to define the contents of a release or a specific shippable product increment. It serves as a guideline that reflects expectations about which features will be implemented and when they will be completed. Some of the key activities involved in release planning are selecting user stories, conditions of satisfaction (goals for the schedule, scope, resources), team velocity and slicing of user stories. Release management metrics are clear across the organization. By enforcing standards and best practices, release planning ensures delivering smoother transitions of release from development activities (projects) to final destination environment by increasing productivity and collaboration but also mitigates release failure. Iteration planning is highly detailed planning where team members determine how many user stories they can complete and deliver during an upcoming iteration. The purpose of iteration planning is to organize the work and define the realistic scope. Iteration planning requires updated backlog prioritized by the product owner and includes discussing and selecting the user stories in the backlog, writing the acceptance tests for these user stories, and breaking and estimating these user stories are some of the activities to be accomplished.
- 31. As a Project Manager, I was extensively involved in the planning stage of all the projects I’ve worked on. Irrespective of the industry domain the project belongs to such as Information Technology, Healthcare, Construction, and Pharmaceutical; each project has its own challenges. By planning adaptively, I was quite successful in removing uncertainties, mitigating risk and avoiding rework. If you have any questions regarding adaptive planning, please send me an email to [email protected].