The picture above shows the traditional, bell-shaped product life cycle curve with three key events: launch — the product first becomes available; achieving product-requirement fit (PRF) — the product has a settled features list and requirements backlog; and end of life — when it’s decided to discontinue using the product.
In order to leverage the product life cycle, 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 cost saving products cost saves are usually used and if the product exists for use by other products or services, then the number of active users might be instead.
How to Determine Whether to Use Scrum?
What determines when best to apply scrum if the amount of uncertainty around the product, it’s features and requirements. If there is a lot of uncertainty, and things may change, it is best to iterate through product builds and Scrum is a very good development framework for managing that. The following questions can be used to consider how much uncertainty there is around the product and consequently if Scrum should be used by the project:
- Is it understood how to address market needs or solve the user’s problems?
- Is it known how to develop, market, and sell the product?
- Can the users state which functionality is required 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 goals?
If the answer to these questions is “no” or “don’t know”, then there is a high degree of uncertainty around the product and Scrum is probably the best framework to use. If the answers are “yes”, then the next sprint retrospective can be used to investigate if your process is still helpful, or if you should switch to an alternative.
When best to use Scrum
The younger, and less mature the product is, the more it is likely to benefit from Scrum. This is because when working on a brand-new product, or a product that has never been used by an organisation if it’s an internally used product, you typically face many unknowns and a substantial amount of uncertainty and change. The following are factors in determining the level of uncertainty and if things are likely to change:
- When it’s not fully understood the value the product should create for its users or customers
- When the features and user experience (UX) the product should provide are not clear
- When the business goals it should serve and the business model it should use are still being worked through
- When the technologies that should be used to develop the product might change based on testing and feedback.
In a situation where much is uncertain, the 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. In such a situation, where accelerating learning and mitigating the risk of developing the wrong features, or providing the wrong UX, or applying the wrong technologies is important, Scrum would be the best methodology.
When Best to Use an Alternative Agile Process
As your product grows and eventually matures, the amount of uncertainty and change gradually declines. After the product achieves a good fit of its requirements, you usually understand how to meet the user needs, and know how to develop, market, and sell the product. The focus at this point for the project tends to switch to penetrating the market and fending off competitors by keeping the product attractive and refining it – not specifically testing an assumption or delivering new functionality as these things would have been tested or delivered in prior releases such as product launch or further updates. This stage of the product lifecycle might result in smaller, often incremental product changes that can be done independent of each other. A good example is mobile phones, where the manufacturer largely optimises existing features like camera and battery life. Scrum consequently might become less helpful than other Agile frameworks at these life cycle stages and could be replaced by something that fits better.
If, however, you decide to revitalise a maturing product and extend its life cycle (shown in the diagram above as the point of New Feature and Product Life Extension), for instance, by taking it to a new market, you usually face a significant amount of uncertainty and change and Scrum would be more useful.
What are the Alternatives
Once the 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 a better choice. 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 useful for minor incremental enhancements and bug fixes and to quickly test smaller ideas.
