Photo by Charlotte Coneybeer on Unsplash

Is Scrum Right for Your Product?

Published on 19th September 2016 Last Updated on: 9 Oct 2023

Scrum offers a powerful way to develop products. In fact, it is often seen as the standard way to create digital products, and I have met more than one company where the product managers were suddenly told to be agile and do Scrum. But like every process, Scrum has its benefits and limitations. Is it the right approach to develop and grow your product? Or would you be better off using an alternative?

When is Scrum Most Helpful?

A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. This means that not every product will benefit from Scrum: Products that are maturing or declining won’t benefit from Scrum—at least not to the same degree.

scrumandproductlifecycle

The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch—the product first becomes available; achieving product-market fit (PMF)—your product is ready to serve the mainstream market; and end of life—you decide to discontinue the product. Note that your product’s actual trajectory may differ significantly from the one above: it may be much steeper or flatter. To to leverage the product life cycle model, you have to define the business benefits your product delivers and then track them over time. For revenue-generating products, revenue is commonly used, for example. But if your product exists to sell another product or service, then the number of active users might be the appropriate metric.

The younger your product is, the more it is likely to benefit from Scrum. Why? When working on a brand-new product, trying to achieve PMF, or struggling to keep the product growing, you typically face many unknowns and a substantial amount of uncertainty and change. You may not fully understand the value it should create for its users and customers, the features and user experience (UX) it should provide, the business goals it should serve and the business model it should use, and the technologies that should be used to develop it.

Scrum is a great fit at this stage: Your product will benefit from an iterative, cyclic process that allows you to quickly test an assumption, address a risk, generate new insights, and come up with new ideas. This accelerates learning and mitigates the risk of developing the wrong features, providing the wrong UX, and applying the wrong technologies, as I describe in more detail in my post The Scrum Cycle.

But as your product grows and eventually matures, the amount of uncertainty and change gradually declines. After achieving PMF, you usually understand how to meet the user needs, and know how to develop, market, and sell the product to the mainstream market. Your focus tends to switch to penetrating the market and fending off competitors by keeping your product attractive and refining it. This typically results in smaller, often incremental product changes. A good example is the latest iPhone 7, where Apple largely optimised existing features like camera and battery life. Scrum consequently becomes less helpful at these life cycle stages: The development team members are often no longer required to work together towards a shared goal to test an assumption or to deliver a piece of functionally.

If, however, you decide to revitalise a maturing product and extend its life cycle, for instance, by taking it to a new market or unbundling a bigger feature, you usually face a significant amount of uncertainty and change. In the picture above, the life cycle extension is shown by the arrow that reverses the ageing process of the product and takes it back into the growth stage. In this case, Scrum becomes helpful again!

If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product. Do you understand how to address the market needs and solve the users’ problem? Do you know how to develop, market, and sell the product? And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved? Do you mainly provide incremental enhancements or bug fixes? Are the architecture and technologies fit for purpose and stable? Are you regularly struggling to agree on a shared, meaningful sprint goal? If the answer to these questions is yes, then Scrum is probably not the best framework for your product. To gain more clarity, use the next sprint retrospective to investigate if your process is still helpful, or if you should switch to an alternative.


What’s the Alternative?

Once your product no longer exhibits a significant amount of uncertainty and risk, is growing steadily, or has started to mature, a Kanban-based process may be the right choice, as the following picture illustrates.

scrumkanbanandproductlifecycle

Unlike Scrum, Kanban does not regard protected, goal-driven iterations as mandatory. You can use it to implement an agile process with the flexibility to work on different items and release them individually at different times. This is particularly handy for incremental enhancements and bug fixes and to quickly test smaller ideas.

I therefore suggest that process follows product: You should choose the process that is best suited to provide a successful product—a product that does a great job at creating value for the users and for the business. There is no one right way, no silver bullet. Neither Scrum nor any other framework is always the best fit. As a consequence, you may well have to adjust and change your process across over time. Use the retrospectives to regularly enquire if your current process is fit for purpose and adapt and change it as appropriate.


Mix and Match

The picture above seems to suggest that you face a stark choice—either Scrum or Kanban. But that’s just a simplification to help you choose your primary process. You can, of course, combine Scrum and Kanban. You may decide, for example, to apply Scrum to develop new features and Kanban to fix bugs, as I describe in my post Succeeding with Innovation and Maintenance. Finally, you can also use Kanban for product strategy validation activities, as I recommend in my book Strategize.

Post a Comment or Ask a Question

14 Comments

  • Scott Cunningham says:

    Given that this article is 5 years old, would you change anything today?

    • Roman Pichler Roman Pichler says:

      Hi Scott, Your question triggered me to review the article and make small adjustments to it. But it essentially stayed the same. While I regularly update my articles, the age alone does not indicate that the concepts and techniques covered are no longer relevant. Take the product life cycle model used in the article. It was developed in the early 1960ies and continues to be a very valuable tool for product people. Hope this helps.

  • Umang says:

    Hi Roman,
    Great post. I agree with your suggestion that process should follow the product.
    It makes total sense that product will benefit from processes like scrum or kanban when there is uncertainity in what to develop and how to enhance the product.
    Incase of a mature product and especially operating in a B2B enterprise environment, where Roadmap is driven by feature requests from the customers, the uncertainty seems to be low.
    In such a case, would the product and team benefit from plan based development approach?
    Would it help to do little more upfront design, a little more architectural clarity and little more upfront requirements, and little more project plan?
    Or not?
    The 3x model of Kent Back tries to explain why waterfall model may work for some product teams.
    Do you feel the same way?
    Would some teams benefit from waterfall model?

    • Roman Pichler Roman Pichler says:

      Thanks for the feedback and sharing your question Umang. I have found it difficult to combine an agile way of working with a traditional, plan-based approach primarily due to the different values and principles being used. I have therefore a preference to apply agile practices across the entire life cycle and adjust the process, as suggested in the article. Does this help?

  • tushar says:

    Hi, thank you for this post I Agree with you that A process like Scrum is a great fit for your product when it is brand-new or young, and when you extend its life cycle, as shown in the picture below. very useful information

  • Harihara Prasath says:

    Especially in the following points:

    Do you understand how to address the market needs and solve the users’ problem?
    Me : If we understood clearly the market needs and if we are constantly solving the user’s problem, then in what way it is not advisable in doing Scrum.

    Do you know how to develop, market, and sell the product?
    Me : If we know how to develop, mark and sell the product, what is there in not executing this with scrum

    And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved?

    Me : If the users confidently tell us what functionalities they required, is it not the expectation for any project? How it differs for not qualifying as a Scrum Project.

    Sorry for my long question. I want to understand better. Thanks in advance for your answer

    • Roman Pichler Roman Pichler says:

      If you thoroughly understand who uses your product and why, and if you understand how to develop it, then you are facing little uncertainty. You can still use Scrum, of course, but you should consider if it is still the best process for you, see my post The Scrum Cycle.

      I don’t think you can and should expect that your users are generally able to tell you what the product should do. I regard it as the responsibility of the product manager/owner and the dev team to discover the right features and UX.

      Hope this helps!

  • Harihara Prasath says:

    Nice Article.

    If you can give more clarity on the below points, it will be of great help

    If you are in doubt if you should use Scrum or not, consider how much uncertainty is present in your product.
    Do you understand how to address the market needs and solve the users’ problem?
    Do you know how to develop, market, and sell the product?
    And more specifically, can the users confidently tell you which functionality they require and which aspects of the product need to be improved?
    Do you mainly provide incremental enhancements or bug fixes?
    Are the architecture and technologies fit for purpose and stable?
    Are you regularly struggling to agree on a shared, meaningful sprint goal?

    If the answer to these questions is yes, then Scrum is probably not the best framework for your product.

    • Roman Pichler Roman Pichler says:

      Hi Harihara, Thanks for your feedback. What makes it difficult for you to apply my advice? What’s unclear to you?

  • Rik Pennartz says:

    Thanks, Roman. I really enjoy reading your posts. They are very helpfull!

Leave a Reply

Your email address will not be published. Required fields are marked *

Sign up for great new content from Roman

Hear about his latest product management work including new articles, videos, podcast episodes, and more.