5. Improving Planning

Taking an empirical approach to delivering complex products in an uncertain and rapidly changing world requires empirical planning. This means that in planning activities, aim to:

  • Enable transparency to progress

  • Set realistic expectations

  • Minimize waste while maximizing value

  • Harness change and new learnings for competitive advantage

  • Have open and honest discussions about the unpredictability and complexity inherent in product development

Business leaders and customers will still—and should—ask questions such as “When will it be ready?” and “How much will it cost?” When you work empirically, your answers to these questions will reflect likelihoods and probabilities rather than commitments and certainties. You cannot perfectly plan complex work, but rather must remain open to change and new knowledge. Even within the time horizon of a Sprint, there are complexities, unknowns, and possibilities for change.

There are four key things a Scrum Team should get out of its planning activities:

  1. Establish a common set of understandings from which emergence, adaptation, and collaboration can occur (agile mindset, empiricism, teamwork).

  2. Establish expectations that progress will be measured against (empiricism).

  3. Convince a source of funding that the ROI of an initiative is worthwhile (agile mindset).

  4. Help people involved in the value delivery process make better decisions (empiricism, agile mindset).

Planning and forecasting encompass a wide range of topics. In this chapter, we will focus on illuminating the following concepts for planning and provide additional resources to explore specific tactics:

  • How Scrum Teams plan empirically and get the most benefits from Product Backlog refinement

  • How Scrum Teams plan effectively to create a “Done” Increment of sufficient value during every Sprint, while incorporating learning and continuous improvement

  • How Scrum Teams can approach release planning without having to plan many Sprints in advance

Planning with a Product Mindset

A product mindset helps Scrum Teams and organizations focus on delivering valuable outcomes rather than just concentrating on the quantity of output.1 It is easier to understand this approach when we compare it with a project mindset.

1. For a more complete description of the differences between a project mindset and a product mindset, see https://www.scrum.org/resources/blog/project-mindset-or-product-mindset.

According to the Project Management Institute (PMI), a project is a temporary endeavor undertaken to create a unique product, service, or result.2 The two key points in this definition are that a project has a beginning and an end date (which creates boundaries around scope and resources), and it is not repeatable.

2. https://www.pmi.org/about/learn-about-pmi/what-is-project-management

When you think about Scrum, you could look at every Sprint as a project. The Sprint has start and end dates, and the Scrum Team produces a unique releasable Increment during that span. Or you could consider a subset of the Product Backlog as a project that encompasses multiple Sprints and achieves a value proposition or business goal through delivery of multiple Increments. The point we are trying to make here is that these concepts are interwoven. However, the challenge arises when you consider how success is often measured.

Measuring Success

In our experience, project success is traditionally measured by answering these three questions:

  • Did you deliver all of the scope?

  • Did you do it within budget?

  • Did you do it on time?

These questions are derived from the Project Management Triangle, also known as the Iron Triangle or the Triple Constraint, illustrated in Figure 5-1.

A triangle representing the constraints in project management is shown. The triangle is named quality and its three vertices are labeled cost, scope, and schedule.
Figure 5-1 Iron Triangle of project management.

The problem with only using these variables as the measure of success is that doing so leaves out valuable outcomes. How do you know if the investment is worth it? How do you know if you need to change direction or if you can stop investing sooner? And even if an organization does measure the ROI against the original business case for the project, that usually happens after the project has completed, so it is too late to matter. Besides, business cases are themselves just educated guesses whose assumptions need to be tested using empiricism.

Planning Empirically

“A plan is simply a guess you wrote down.”3 Instead of doing a lot of analysis and estimation up-front to create a long-term detailed plan, take an empirical approach to planning. Empiricism says learning comes from doing. You plan a little, actually do that work, and then inspect the results, asking “What assumptions have we validated? What did we learn?” Based on new information, you adapt your plan accordingly. By modifying your plans based on new information, you minimize the risk of complex work in an unpredictable and changing world.

3. https://m.signalvnoise.com/planning-is-guessing/BOOK.

Planning empirically requires transparency. The agile mindset helps remind us that the only measure of progress is a working product. Completing some “activities” doesn’t deliver any value if there is no working product. There is no such thing as 85 percent complete when it comes to a “Done” Increment, or any other complex work. That type of “status update” is often a wild guess at best, and sometimes an effort to avoid difficult questions and conversations. Furthermore, when organizations focus on meeting a schedule and/or budget, they discourage transparency and openness to change and learnings. This actually increases—rather than reduces—risk.

The agile mindset also reminds us to seek to maximize value and reduce waste. Consider how much waste is created when you frequently update long-term detailed plans. How much waste is created by change control processes that create a lot of work to incorporate new information into your plan? What value is potentially lost or delayed when people feel the burden of a heavy change control process and choose to just “stick with the plan and hope for the best”? When teams are pushed to meet a deadline, quality is often sacrificed. Ultimately, this costs you in the longer term because it damages your ability to deliver future value.

Staying grounded in empiricism and the agile mindset will help maintain a focus on a product mindset as a Scrum Team plans the work for the product, from the shorter-term to the longer-term planning horizons. This grounding will also remind everyone that the less history a Scrum Team has (i.e., empirical data) and the further into the future the forecast stretches, the wider the range of unknowns, complexities, and likelihood for change will be.

In Practice: Empiricism Reduces Uncertainty by Taking Action, Not by Planning More

Traditional project management approaches suggest that making more detailed plans reduces risk, but more planning actually just delays confronting risk by making more assumptions. This is why so many traditional projects fail. For example, describing a detailed architecture for a product does nothing to tell you whether that architecture will actually work. The best way to understand whether something will work is to build a critical subset of the solution and try it out.

This point is even more true for ideas about what consumers will like. The only way to know for sure whether customers will like your product is to actually deliver something minimally usable, sometimes called the Minimum Viable Product (MVP).4

4. For more information on the Minimum Viable Product concept, see https://www.agilealliance.org/glossary/mvp.

The cone of uncertainty5 is a project management model that expresses the reduction in uncertainty of outcomes as an organization gathers more information. At the start of a release, uncertainty about what to build and how to build it can be quite high. Plans will be quite “rough”—perhaps nothing more than desired outcomes, some possible features and functions to achieve those outcomes, and a rough idea of desired release dates based on market conditions. As the Scrum Team completes Sprints, they gather information and refine the Product Backlog, and they develop a better understanding of how much work they will need to do to achieve the desired outcomes. The Product Owner can trust the empirical process, knowing that something of value will be “Done” at least by the end of every Sprint. In turn, the new information and new learnings will guide the Product Owner in deciding to continue forward, adapt the direction, or stop investing.

5. https://www.construx.com/books/the-cone-of-uncertainty

Creating Alignment

Planning is only effective when there is alignment to value delivery in the organization. Alignment is about everyone moving in the same direction. You can visualize planning product delivery as peeling the layers of an onion, as illustrated in Figure 5-2.

The various levels of planning in product delivery are shown. They are as follows: daily plan, sprint plan, release plan, product strategy, product vision, business strategy, and company vision.
Figure 5-2 Planning product delivery requires alignment through the various levels in an organization.

The Scrum Framework directly addresses the two innermost (i.e., shorter-term) levels of planning. The Daily Scrum is a plan for the next 24 hours to make progress toward the Sprint Goal. The Sprint Goal is created in Sprint Planning and is informed by an ordered Product Backlog. The Product Owner’s strategy for moving toward a Product Vision is essentially reflected in the Product Backlog. Finally, to maximize value, the Product Vision and strategy must be aligned with the organization’s business strategy.

Each layer represents a different planning horizon in the context of the product and how it fits into the direction of the larger organization. Looking at the bigger picture, these questions are likely to come up:

  • How far in advance should you plan, and at what level of detail for each layer?

  • How frequently should you inspect and adapt your plans at each layer?

  • Who should be involved in planning for the outer layers that go beyond the Scrum Team?

The answer to all of these questions is “It depends!”

It depends on the complexity of your product and its relationship to the greater organization, as well as the environment in which it is used. Consider how the planning cycles in your organization enable empirical planning and alignment between the bigger picture business objectives and the work being done by the Scrum Team.

Product Backlog Refinement

Product Backlog refinement is an activity that helps create alignment. The Product Backlog is the plan for future Sprints; it is a living plan, open to change and continually being evolved, as long as the product exists. Therefore, Product Backlog refinement is how Scrum Teams plan an upcoming Sprint, as well as future Sprints, which then impact the higher-level plans for business areas.

In our training classes, people often ask why Product Backlog refinement is not an event in Scrum. Because this activity is highly context dependent, it is an aspect of the Scrum Team’s process—and is left to the team to determine the most effective practices and timing.

Many Scrum Teams struggle to find their rhythm with Product Backlog refinement. Common questions arise around how frequently to do it, how much time to spend on this activity, how much detail to get into, who is involved, and which practices to use. Again, this is something best determined by the Scrum Team and best learned by experimenting, inspecting, and adapting.

Minimum Viable Product Backlog Refinement

The goal for Product Backlog refinement is minimal but sufficient. Product Backlog items (PBIs) have the attributes of a description, an order, an estimate, and value. This set of attributes reflects the minimum amount of information that an effective team should have before starting on a piece of work. Of course, all of these attributes are open to change as more information is learned.6

6. ScrumGuides.org

As PBIs become closer to being pulled into a Sprint, the Scrum Team will make some effort to break them down into smaller pieces and add details. PBIs will be deemed “ready” when the Development Team has a sufficient shared understanding of the value desired and believes the item to be small enough to get it to “Done” within a Sprint.

In Practice: Do You Need a Formal Definition of “Ready”?

We have seen the complementary practice of a formal definition of “Ready” used well, and we have seen it used poorly. Such a definition may be useful when a Scrum Team often runs into dependencies or gaps in understanding among the Development Team members that would be best handled during the refinement process, to avoid delays once a PBI is brought into a Sprint. Here are a few examples:

  • Text requires review by the legal department

  • Updated graphics are needed that align with branding/style guidelines

  • Hardware or software needs provisioned and configured

The way not to use a formal definition of “Ready” is to treat the PBIs like “locked down” requirements documents, in which all details must be written out and approved. This leads to an atmosphere of valuing “contract negotiation over collaboration.”7

7. This is the opposite of valuing customer collaboration over contract negotiation, one of the core values in the Manifesto for Agile Software Development.

Do not build an artificial barrier that prevents work from flowing to the Development Team or that means the Development Team cannot collaborate with the Product Owner or the relevant stakeholders. PBIs will continue to be refined even during the Sprint because more will be learned.

Scrum Teams should seek six benefits from Product Backlog refinement activities:

  1. Increased transparency. The Product Backlog is the “single source of truth” for what is planned in the product. Adding details increases transparency to what you plan to deliver, as well as your progress.

  2. Clarification of value. When you clarify the details around value, the outcomes you are trying to achieve with the PBI become clearer. This helps the Development Team build the right thing to meet the need. This can affect what is requested, the estimate, and the order as the Product Owner and the Development Team figure out what is actually needed.

  3. Breaking things into consumable pieces. You want PBIs to be small enough that a Development Team can complete more than one in a Sprint. Having more than one PBI in a Sprint gives the team more flexibility to meet a Sprint Goal and deliver a “Done” Increment.8

    8. For more information on how to split user stories into smaller PBIs, see https://agileforall.com/patterns-for-splitting-user-stories/.

  4. Reduction of dependencies.Dependencies often turn into impediments. While you may not be able to avoid them all, try to reduce them where possible. At the very least, you want the dependencies to be transparent.

  5. Forecasting. A refined Product Backlog combined with historical information about the Scrum Team’s ability to deliver a working product helps you forecast. Forecasting for some products needs to stretch several Sprints into the future to help communicate release expectations to stakeholders. For other products, forecasting beyond the current Sprint is unnecessary. Most products fall between these two extremes.

  6. Incorporation of learning. Empiricism is about incorporating the learning you gain as you build the product, as you better understand how to realize product value, and as you see changes happening in your environment.9

9. Learn more about these benefits in this blog post: https://www.scrum.org/resources/blog/art-product-backlog-refinement.

With experience, you will find how much refinement is right for you to make planning easier while minimizing potential waste created by spending too much time refining.

Estimation

The purpose of an estimate is to help a Development Team forecast what can be developed in a Sprint and to help a Product Owner manage a Product Backlog, specifically by determining whether an item has enough assumed value to warrant the investment in doing it (i.e., ROI). When we start to think about the bigger picture of forecasting and planning beyond a Sprint, estimates can help with this effort as well.

An estimate is really just a “guess” you make based on the best information you have about the size, effort, and complexity of a PBI. Because it is just a guess, you should assume every estimate is wrong; you should not expect estimates to accurately predict the future when you are doing complex work. When people are expected to be accurate in their estimates (either by a direct incentive or by an implicit measure of performance), this often leads to “gaming of the numbers.” This then potentially leads to inflated estimates (which means they are no longer transparent and no longer serve their purpose) or cutting corners to meet an estimate (which means the Increment is no longer transparent and there is no way to deliver value).

Scrum does not prescribe how to estimate, but it does state that the Development Team owns the estimates because they are the ones doing the work. These team members are accountable for creating the “Done” Increment, and they own the Sprint Backlog, which means they decide how much work to pull into the Sprint. This is an important aspect of self-organization.

You can approach estimation in two different ways: You can estimate the effort necessary, represented by hours or working days, or you can do relative estimation, which means you compare a chunk of work to something else based on an understood reference point. Empiricism and an agile mindset bias teams toward relative estimation because that approach helps teams incorporate complexity and unknowns, is based on experience with known work, and minimizes the amount of time spent on estimation (i.e., potential waste). The techniques you use are not as important as how you are using them and which benefits the Scrum Team is gaining.

In Practice: Leverage Teamwork, Empiricism, and an Agile Mindset with Relative Estimation Techniques

We have experienced success by helping teams select a relative estimation technique and leverage the power of group estimation. Here is a brief description of five commonly used relative estimation techniques:

  • Story points: PBIs are estimated using a series of numbers, often the Fibonacci sequence (1, 2, 3, 5, 8, 13, etc.), to assign points to an item based on size and complexity.

  • T-shirt sizes: PBIs are estimated using T-shirt sizes such as X-Small, Small, Medium, Large, and X-Large.

  • Animals, fruits, etc.: PBIs are estimated using a physical object to represent relative size. For example, a watermelon is bigger than a cantaloupe, which is bigger than a grapefruit, which is bigger than a lime, etc.

  • “Same-size” items: PBIs are sliced and split to have them all be roughly the same size.

  • “Right-size” items: Essentially, this is breaking things down small enough that at least one item can be delivered in a Sprint.

Research indicates that group estimation is more accurate than individual estimation. It requires that groups have diversity and independence and that authority is decentralized within the group. The best decisions come from having productive conflict such that all perspectives are heard and the group can come to consensus.10

10. Wisdom of Crowds by James Surowiecki (Anchor, 2005).

Consider engaging the entire Scrum Team in estimation. All the Development Team members can offer unique perspectives based on their own experiences, knowledge, and skills. Although the Product Owner does not estimate the work, this person’s participation helps clarify the purpose and desired value of the PBIs. The Scrum Master helps ensure the team is collaborating well and doesn’t fall into antipatterns involved with estimation (e.g., anchoring, analysis paralysis).11

11. To learn more about estimation techniques, see the book Agile Estimating and Planning by Mike Cohn (Prentice Hall, 2005).

Breaking PBIs Down to Focus on Valuable Outcomes

Teams often struggle with breaking down big features and functions into valuable PBIs that are small enough to get to “Done” in a Sprint. We often see the focus being more on “small enough” while losing sight of “valuable.”

Product Backlog refinement brings transparency to both the Scrum Team and the stakeholders about what the team is planning to build to deliver value. The Scrum Team needs to have a shared understanding of the desired outcomes to build the right thing. The Product Owner gains more flexibility and understanding of how to order the Product Backlog to optimize value. Stakeholders gain more transparency into how the work the Scrum Team is doing at the Sprint level connects to the larger things the business wants to achieve for the product.

Consider collaborative visualization techniques such as User Story Mapping, which enable the Scrum Team and stakeholders to see both the big picture and possible ways to break it down, while not losing sight of the user outcomes and value.12

12. To learn more about user story mapping, see the book User Story Mapping by Jeff Patton (O’Reilly Media, 2014).

No matter which techniques you employ, be sure that your Scrum Team and stakeholders are getting the six benefits described previously from breaking down the PBIs. Know why you are using a technique, and regularly inspect on how well that technique is meeting your needs. Adapt techniques to work better for you.

Planning a Sprint

In the process of planning a Sprint, the Scrum Team should answer these three questions:

  • What is the right work to focus on this Sprint, and how well do we understand it?

  • How much can we get “Done” in a Sprint?

  • How much time do we need to spend on improving how we work this Sprint?13

    13. Refresh your knowledge of the basics of the Sprint Planning event (purpose, inputs, outputs) here: https://www.scrum.org/resources/what-is-sprint-planning.

We’ve already talked about the first question. We will focus on the other two questions here.

How Much can you Get “Done” in a Sprint?

As they plan the Sprint, the members of a Development Team select items from the Product Backlog that they believe they can complete in the current Sprint to achieve the Sprint Goal. How much they can get “Done” depends on their experience working as a team, the effectiveness of their team’s processes, and their demonstrated ability to do similar work.

As Scrum Teams grow their team identity and clarify and improve upon their ability to build quality releasable Increments, they will get better at having an intuitive sense of how much product they can build in a given period of time. The Sprint helps provide a cadence, or rhythm, for this intuitive sense to grow over time.

Here are some common challenges that will make it difficult to develop that intuitive sense:

To overcome these challenges, strive to create more stability and greater focus. Can team composition change? Yes, but it should be done intentionally and in a way that provides the team with sufficient control. Can a Sprint length change? Yes, but it should be done intentionally. Can there be interruptions? Yes, but they should be for good reasons and be done in ways that minimize their negative impacts.

And the reality is that the longer a Sprint is, the harder it is to plan. Longer Sprints have more complexity and more unknowns. If we asked you to plan out every single thing you can accomplish in the next month, that challenge would likely feel very overwhelming. But if we asked you to plan out your accomplishments for the next week, that would probably seem much easier.15

15. To learn an approach to facilitating a Sprint Planning event, watch this short video: https://www.scrum.org/resources/effective-sprint-planning.

In Practice: How Long Should the Sprint Be?

”A Sprint should be as short as possible and no shorter.” –Ken Schwaber

Scrum tells us a Sprint must be one month or less. But how do you know what is right for you? Two factors determine Sprint length:

  1. How quickly does the business need to change direction?

  2. How quickly can the Development Team create a “Done” Increment?

The first question is about enabling the business to take advantage of opportunities, respond to changes in the market, and manage its investment risk. A Product Owner will also need to consider how frequently feedback and new information will be collected and incorporated given the inspection and adaptation cycle of a Sprint.

Often we see that Scrum Teams focus on the second question. But if the answer to the second question is limiting business agility, then the Development Team should consider how to improve the necessary processes, tools, and capabilities to meet the business need. As an example, if the marketplace changes so frequently that there will never be four weeks of stable work available, then a four-week Sprint does not meet the business need.

Once a Sprint starts, its length doesn’t change. However, a Scrum Team can choose to change the length of a Sprint for continuous improvement (usually determined in a Sprint Retrospective as the current Sprint concludes), with the decision applying to all future Sprints. The point is to allow the team to settle into a rhythm.

It may be helpful to align Sprint length with an “organizational heartbeat.” For example, when multiple Scrum Teams are working on one product or product suite, coordinating work and resolving dependencies through aligning cadence becomes more important.

In Practice: Forecasting a Sprint with Empirical Data

Velocity is a complementary practice that provides an indication of the average amount of Product Backlog turned into a “Done” Increment during a Sprint by a Development Team. It is tracked by the Development Team for use within the Scrum Team. When historical data is gathered over time, a Scrum Team gains an understanding of the rate at which work has been completed and then can use this knowledge to forecast future work (i.e., to select PBIs for the Sprint Backlog).

However, velocity can easily be misused. It is crucial to understand what velocity is not:

  • A performance measure of the Development Team

  • A promise of what will be delivered in the future

  • A way to compare Scrum Teams or Development Teams

  • A way to compare individuals on a Development Team

  • An indication of “how hard” a Development Team is working

In Practice: Probabilistic Forecasting

Probabilistic forecasting is an approach by which historical process data is used in conjunction with a statistical sampling method (e.g., Monte Carlo simulation) to make a prediction about when an item or items will be completed. This technique is popular with flow-based processes, as flow metrics are particularly conducive to statistical analysis.

The output of such a forecast is a statement about the future, cast in probabilistic terms within some agreed confidence level. In other words, a probabilistic forecast includes a range of possible future outcomes as well as a confidence level of that range occurring. For example, a team might use historical cycle-time data to off er an expectation that individual items will flow through their process in “8 days or less 85 percent of the time.” Or they might use historical throughput data as input into a Monte Carlo simulation to forecast the chance of completing all items in the Product Backlog as “on or before October 1 with a 95 percent confidence.”

The power of probabilistic forecasting lies in the fact that it embraces the intrinsic uncertainty associated with predicting the future. Whenever uncertainty is present, a probabilistic approach is warranted. Moreover, understanding the probabilities associated with certain outcomes is advantageous when assessing the risk that accompanies a given plan.16

16. For more details on probabilistic forecasting, see the book When Will It Be Done by Daniel Vacanti: https://leanpub.com/whenwillitbedone.

How Much Time Should You Spend on Improving This Sprint?

There is always pressure to deliver more value. Unfortunately, that often gets interpreted as “deliver more stuff.” We often see that to deliver more value, Scrum Teams need to focus on improving how they work together, improving their tools, removing technical debt, and incorporating new learning.

In 2017, the Scrum Guide was updated to make explicit that the Sprint Backlog must include at least one high-priority process improvement identified in the previous Sprint Retrospective.17 How much time is spent on continuous improvement is left up to the Scrum Team to decide. If a team is still struggling to create a “Done” Increment during every Sprint, the team members will likely need to spend more time on improving their practices, tools, and interactions. Of course, this means taking on less work right now, while acknowledging that this investment in improvement will create opportunities to increase the flow of value in the future.

17. This has always been the expectation since the inception of Scrum, because inspection without adaptation is pointless.

How Far Ahead to Refine

A Product Owner ensures that there is a healthy Product Backlog of “just enough” refined work understood by the Development Team. The desire for prioritization is made clear through the order of the Product Backlog and an overall understanding of value and how it relates to business goals. The Development Team determines how much they can consume in a Sprint, and they learn to find the right balance over time. They can use empirical data—specifically, how much of the Product Backlog they have finished in previous Sprints—to forecast how much they might finish in future Sprints, but this forecast also takes into consideration how much change is expected in the menu and their appetite during the period being forecasted.

You may also need to forecast at higher levels. Perhaps you need to forecast when a subset of PBIs is likely be delivered to achieve a business goal … and then the next business goal … and the next. Perhaps you need to forecast when a particular PBI in the Product Backlog is likely to be delivered.

Planning Releases

The purpose of planning is to communicate and manage expectations. We also plan so as to have something to measure progress against. As part of the rapid pace of modern society, people are seeking faster solutions to their concerns. The way to delight them is to either preempt or cultivate the desire for a feature, or be exceptionally responsive. This approach lies at the heart of Scrum—that is, in being able to release as quickly as necessary given the context of the product and the market in which it is used. A release is how you actually deliver value to users/customers.

The word “release” appears frequently in the Scrum Guide, yet Scrum does not prescribe release strategies or release planning. What Scrum does tell us is that as a part of the accountability to optimize value, it is the Product Owner’s responsibility to decide when to release a “Done” Increment.

Some people ask, “Why isn’t release planning a Scrum event?” Well, you don’t have to release at all in a Sprint. In fact, you could go several Sprints before releasing. Or you could release multiple times in a Sprint, perhaps every time a PBI meets the definition of “Done.” Netflix engineers release thousands of times per day because they are running lots of small experiments, the risk of any one of those changes causing a problem is very low, and the cost of backing out the change is also very low.18 By contrast, a team that builds software for implanted medical devices will release very infrequently because the risk of causing harm if an error occurs is very high, and the cost of a re-release or product recall is exceptionally high. Each product will have an ideal release frequency that reflects its risk and cost of change.

18. For a brief introduction to modern release practices, see https://medium.com/data-ops/how-software-teams-accelerated-average-release-frequency-from-three-weeks-to-three-minutes-d2aaa9cca918.

How Large Should a Release Be?

The release strategy employed will depend on the type of product, the environment in which the product is used, and the capabilities of the Scrum Team. Therefore, the level of planning needed and the way to do the planning will be highly dependent on the release strategy. Release planning is best considered a part of the Scrum Team’s empirical process, so that the team determines when and how best to do it to maximize benefits and reduce waste.

How Small Can a Release Be?

The smallest release you should consider is a new or improved outcome for a single persona. If you don’t deliver at least that much to your customers, you will go through a lot of effort and your customers will not receive any benefit. If you deliver more than one new or improved outcome, you have prevented your customer from receiving the benefit of one of the outcomes earlier.

It may not be possible for you to release a single outcome at a time. You may have too much manual effort or complexity in your release process to make this possible. You may lack sufficient testing to ensure quality, or you may lack automation of key release activities. No matter how frequently you release, or how small the Increment is, removing these barriers will help you to improve the quality, cost, and frequency of your product releases.19

19. For more information about release planning strategies, see The Professional Product Owner by Don McGreal and Ralph Jocham, also part of the Professional Scrum Series by Scrum.org, published by Pearson Addison-Wesley (2018).

Summary

Plans are living artifacts: The activity of planning is what matters. Work on what you can control—creating the shared understanding, getting really good at delivering smaller pieces of value, and making sure you’re always working on the next right thing. It will then be easier to adapt your plan when change inevitably happens.

The Product Backlog combined with empirical data is all you need to plan and forecast. It really is that simple. Over time, you will adjust your plan as you learn by doing the work and observing what is changing around you.

  • The Product Backlog is the plan for future Sprints.

  • The Sprint Backlog is the plan for the current Sprint.

  • Product Backlog refinement is the planning activity.

Seek to maximize the value of planning activities while reducing waste. Accept that plans will evolve, and be vigilant about evolving plans as you learn. Enable transparency to progress so that you can set realistic expectations, and have open and honest conversations about the inherent complexity and unpredictability in product development.

Call to Action

Consider these questions with your team:

  • Do planning activities feel light or heavy?

  • How well do you collaborate as a team for planning and forecasting?

  • How much change do you experience in the Product Backlog from Sprint to Sprint? How much Product Backlog does it make sense to have “Ready”?

  • How well do the Scrum Team and stakeholders understand the value desired for individual PBIs?

  • What benefits would be gained from releasing more frequently? What is holding you back from releasing more frequently?

  • How do planning cycles in your organization enable empirical planning and alignment between the bigger picture business objectives and the work being done by the Scrum Team?

  • What challenges are hurting the most right now? Identify one or two experiments to help improve the effectiveness of planning. For each experiment, be sure to identify the desired impacts and how you will measure them.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.222.238.105