5.4: Agile Estimation and Planning - Video Tutorials & Practice Problems

<v ->Now, let's talk about agile estimation and planning.</v> Agile planning is iterative as compared to waterfall, which defines all the milestones upfront. To explain what it means, let's compare two maps. Iterative planning allows for taking changes into account and adjusting the timelines and targets based on the new data. This can be compared to the difference between a static roadmap and the Waze app. In a static roadmap, all your journey is fixed from the very beginning. In a dynamic roadmap, besides selecting the preferable route and mode of transportation, the route is continuously revisited based on changes in traffic situations, it looks at the selected preferences, and overall, it results in a better, predictable, and much faster trip to your destination. There is no need for change management to account for any changes in the project plan as it is being revisited at regular short increments almost continuously. So there is no impact on the planning time and related efforts, overall, are reduced by default. This flexibility reduces planning overhead and makes changes in planning seamless and easy to manage. From this perspective, agile planning includes multiple levels, moving from long-term planning, which is company's mission and vision to short-term time planning, daily meetings with Scrum teams where participants discuss what they were doing yesterday and their plans and impediments for today. Very short-level planning. These levels are also referred to as an Agile Planning Onion because they can be represented as a set of layers, from long-term to short-term, resembling the process of peeling a metaphorical onion. So how do you interpret the Planning Onion? An agile planning happens continuously at multiple levels. It starts with the company strategy aligns with the mission and vision. These goals are established for longer term intervals, usually one to several years, and reflected in product roadmaps. They focus on why rather than how. The next level is product portfolio. For a bank, for example, the product portfolio would include all the products and services it provides: checking and savings accounts and related services, loans, home, auto, and any others. Also, it may include investment products and services and so on. It is an important decision on which product to provide as part of the portfolio, which to sustain, which to sunset, and which new ones to launch to disrupt the current product line. Think of Product Management Lifecycle, or PML. This level of planning is aligned with this strategy and is also usually done long-term. It affects broad roadmap and defines execution. For each of the products within a portfolio of products and services, there is a product roadmap that is shown on this slide. The product roadmap reflects the product lifecycle end-to-end. Each product experience goes through multiple phases within its existence, and those need to be managed, from inception through design, development, adoption, maintenance, and sunset. This cycle varies for each of the products and depends on the adoption rate, business success, customer feedback, overall market status, company policy, and a lot of other factors, which directly or indirectly affect it. Now, let's talk about release planning. While the concept of a project is not directly relevant in an agile environment, it's frequently used in large enterprises to define major feature releases. Frequently, a concept of the release is confused with software deployment. It's important to distinguish between the two: software deployment results in making a software system or any other relevant functionality available for use. The general deployment process includes multiple activities that result in the ability of the customer to use the software. Those can be frequent, especially with those that have automated and continuous deployment, or do minor changes, or on a continuous basis. Major software release means a new version of the software. It includes significant architecture changes or new features on top of the original functionality. For example, if an online bank provided checking accounts only, providing savings accounts would be a major feature. In order to deliver the functionality of a product within the forecasted milestones, many agile frameworks use incremental delivery. In this case, planning is done in short timeframes, referred to as increments, or, for instance, Scrum. Sprint duration in Scrum, as we know, is usually two, three, or four weeks. During this time delivery team makes a commitment based on their prior capacity and their delivery history. Using empirical data or actual deliverables that they have done before, now they're able to accurately predict the work that they will be able to accomplish during the sprint. Based on the results of the sprint, they adjust the estimation for the upcoming one. Because of the consistency of team composition and the availability of empirical data for analysis, the accuracy of sprint planning really is high. For example, on mature agile teams, it usually exceeds 80%. How is it being done? Team members meet on a daily basis for a brief daily meeting, referred to as Daily Scrum, to align on the tasks that they're working on and to support each other in resolving impediments. So how does agile team achieve high predictability of their planning? Because number one, it's done continuously and collaboratively. As an example, let us review a popular Scrum estimation technique called story pointing. In order to achieve predictable planning outcomes, agile teams estimate their work based on their capacity. In agile, team capacity is referred to as velocity, which is defined as the number of units of work completed in a given time. The unit of work is usually measured in abstract measurement units referred to as story points. As story point is an agile metric used to estimate the effort required for implementing a given user story. This includes the work required to complete this story, and also any approvals and decisions that have to be completed as part of this implementation. This also includes any external dependencies and any other relevant factors. Could be lack of team members experience with the specific type of work or limited subject matter experience, vacations, and so forth. A helpful technique in facilitating story point estimation is done in Fibonacci numbers. As you know, a Fibonacci number is the one that equals to the sum of the previous two: one, two, three, five, eight, 13, and so forth. During the conversation about user point discrepancies, a lot of helpful facts get discovered that some team members are aware and some maybe not aware of. It is a helpful collaboration techniques and not just an estimation technique. Once a team establishes a standard velocity, which is measured in story points, their planning becomes very predictable. Let us review an example. This team's average velocity over the last three sprints is 18. That's what we call empirical data. For the upcoming sprint, they have estimated the top of their product backlog in the following way using Fibonacci numbers as you can see in this slide. Since the team's velocity for the upcoming sprint is 18, the team pulls stories from the top of their backlog into the sprint until they reach 18. In this case, user stories one through five get pulled and reach the total estimate of 15, five plus two, plus two, plus three, plus three. As you can see, the next user story is number six. It is currently estimated as five story points. In this case, the team will skip user story six and pull stories seven and eight into the sprint. If the product owner thinks that user story six is the absolute priority over seven and eight, they can decompose user story or split it into several, smaller user stories. For example, if user story six is to search for a product, they would decompose it into search parameters: by name, by category, by manufacturer, and so forth. If it is a user form, they can decompose it by creates, reads, updates, and deletes, or so-called CRUD functionality, and so forth. Overall, during release planning, an agile team schedules delivery into iterations or sprints. They use the prioritized user story backlog to move user stories and sometimes even epics into a specific iteration. They do it based on the effort required and team velocity. Color coding usually reflects one epic, which is a significant feature represented by multiple user stories, so that in the release plan, the product owner can see which features can be released to the customer after each specific sprint. So now that we know how planning is conducted, let us discuss when it is done. To explain this, let us review the Scrum cadence that is already familiar to us.