Tag Archives: complexity

If you grew up as a teenager in the 1980ies like me, you are probably familiar with the quote “There can only be one” from the first Highlander movie. Interestingly, this statement is also true for product owners: There should only be one product owner per product. But don’t worry: You don’t have to become an immortal warrior to understand the Highlander principle. Reading this blog post will do the trick.

There can be many

Traditionally, product ownership tends to be distributed across several individuals: A product marketer, for instance, writes a product concept or market requirements specification, and a product manager turns it into a product requirements specification. A project manger is then tasked with executing the project, and works with a business analyst, requirements engineer, or architect to analyse and refine the requirements.

While distributing product management responsibilities supports a linear, phase-and-gate-based process, it is not well suited for an agile environment characterised by rapid delivery and fast learning. Additionally, the handoffs between the different individuals can cause defects, delays, loss of information, and other waste; decision-making can be slow and may result in weak compromises; and if the product fails, a blaming game is likely to start.

“There can only be one”

The alternative is to put one person in charge of the product; the individual leads the product development and owns the product on behalf of the company. This integrates strategic and tactical product management aspects. It unites authority and responsibility, and speeds up decision-making.

Meeting the user needs, creating a desirable user experience, and designing a sustainable business model receives the attention and leadership it requires. It increases the likelihood of realising the vision by delivering an attractive, well-rounded product.

“We are brothers”

Just like Connor, the main character in the Highlander movies, needs friends and allies, so does the product owner. To mitigate the risk of a single product owner being overworked or making suboptimal decisions, the Highlander principle must be complemented by collaboration: Leveraging the ideas of users and customers by gathering feedback on working software; and using the knowledge and creativity of the development team by jointly grooming the product backlog.

Immortals Only?

Working with a single product owner role can be particularly challenging on complex products or large projects. But you certainly don’t have to be an immortal or in the movie business to apply the role effectively. On complex products or large projects, you have two options: You can either employ a product owner hierarchy with a chief product owner in charge of the entire product and product owners responsible for features.

The alternative I prefer is to break up complex, feature-rich products into several lean, vertically aligned sub products, each owned by a single product owner.

A benefit of working with a product suite is that the sub products can be developed and released largely independently. Additionally, scaling issues can be avoided or at least reduced.


Learning from user feedback quickly requires effective decision-making. By putting one person in charge of the product, rapid experimentation, learning, and delivery are facilitated. Combining strong product leadership with collaboration and teamwork increases the chances of creating a great product.

No immortal warriors required. Promise.

“Which project is best suited to pilot Scrum?” is a question I get regularly asked in my workshops and training courses. While it is always important to carefully consider the specific situation of an organisation, I have found the following six criteria helpful to select the right agile pilot project:

  1. Small: Your pilot project should be small and consist of no more than two to three teams. Large-scale agile development introduces additional challenges and requires further practices. If you must scale, start with one or two teams and slowly add more teams by splitting the existing teams and adding new members.
  2. Important: Make sure that your pilot is relevant to the organisation. Otherwise skeptics might dismiss it as a “pet project” and undermine the buy-in for the new approach. But avoid mission-critical projects – development efforts whose success severely impacts the organisation. Agile software development is a disruptive process innovation for most organisations. It requires the ability to experiment, to make mistakes, and to learn from them.
  3. Independent: Choose a project that has few dependencies on other teams. Having to coordinate with other projects or different groups adds a level of complexity and makes the disciplined application of agile practices difficult – particularly if the other projects follow a different process. If all you have to choose from is a large, complex project then look for a subproject with few dependencies to pilot your agile approach.
  4. Collocated: Start with a collocated agile project and avoid distributed development efforts, as these make effective collaboration more difficult and require additional practices and tools. Jointly writing user stories, pair programming, and having effective sprint review meetings become much more challenging, for instance.
  5. Software only: Limit your agile pilot to software development. This reduces the added complexity that arises when other disciplines such as hardware and mechanics are involved. Agile software development practices are also well understood. That’s true to a much lesser extent for hardware and mechanical engineering.
  6. New product development: Select a new product development project rather than updating an existing product if you want to try out Scrum. This allows you to explore how an idea is best transformed into a shippable product using agile practices. It frees you from worrying about a legacy code base that may be difficult to understand and lack the necessary tests. What’s more, Scrum is particularly well suited to cope with the flux, uncertainty, innovation, and risk that are characteristic of new product development.

Before you now select your pilot project or decide to delay experimenting with agile practices, consider the following advice:

  1. Know your goal: Understand why you want to try out a certain agile approach and what benefits you expect – even if it’s just to see what all the hype is about.
  2. Just do it: While it is helpful to look for the right pilot, nothing beats applying agile practices – even if you can only use selected techniques within your established process.

“What I hear, I forget.
What I see, I remember.
What I do, I understand.“
~ Confucius ~

“Ready are you? What know you of ready?” says Yoda to Luke Skywalker in the Star Wars movie “The Empire Strikes Back”. Just as it’s important for Luke to understand what “ready” means, so is it for product owners. Luckily, you don’t have to train as a Jedi for many years to find out. A few minutes will do.

Why Ready Matters

The idea that the high-priority product backlog items should be “ready” or “workable” dates back to the first Scrum book published in 2002. Ready items can be pulled into the sprint by the team and quickly turned into a product increment, as the following image illustrates.

If the user stories that are likely to be worked on in the next sprint aren’t ready, then the team cannot create a product increment. It is therefore important to ensure that there are enough ready items on the product backlog. Consequently, my Product Canvas uses a dedicated ready section, as the picture below shows:

What Ready Means

A “ready” item should be clear, feasible and testable, as I suggest in my book Agile Product Management with ScrumA story is clear if all Scrum team members have a shared understanding of what it means. Collaboratively writing user stories, and adding acceptance criteria to the high-prtiority ones facilitates clarity.

An item is testable if there is an effective way to determine if the functionality works as expected. Acceptance criteria ensure that each story can be tested. As a rule of thumb, I like to employ three to five acceptance criteria per user story.

A story is feasible if it can be completed in one sprint, according to the definition of done. This implies two things: The item must be small enough, and it must not be too complex. I prefer to work with stories that can be implemented and tested within a few days by the way, as this allows the product owner to provide feedback on the software during the sprint.

Ready stories are the output of the product backlog grooming work. To put it differently, your grooming activities should result in ready stories.

What a Ready Story Looks Like

A ready story is a detailed user story with a narrative and acceptance criteria. It should also be clear if there are any story-specific operational qualities such as performance, and  what user interface design should roughly look like. I prefer to capture the qualities on constraint cards, and the design on a piece of paper. The artefacts are simply attached to the story, as the picture below illustrates:


“A Jedi must have the deepest commitment, the most serious mind,” continues Yoda in the Star Wars episode. Similarly, you should be committed as the product owner to creating high-priority product backlog items that are clear, feasible, and testable.

Remember: A sprint is a function that takes high-priority items and turns them into a product increment. If you don’t pay attention to what goes into a sprint, it’s garbage in, garbage out. And garbage, as we know from the first Star Wars movie, is not a good place to be stuck in.

The product backlog is a beautifully simple artefact – a prioritized list of the outstanding work necessary to bring the product to life. In reality, many product backlogs are large and unwieldy – rather than simple and concise. If you regularly groom your product backlog but still struggle with its size and complexity, then you may have a backlog that contains items from more than one product: requirements describing different products but kept in the same backlog. This may be due to one Scrum team developing several products concurrently or creating a new software system while maintaining its predecessor.

If that’s the case, break up your product backlog and create a separate backlog for each product. This will not only result in smaller backlogs that are easier to groom. But it will allow you to better prioritize which product takes priority – the development of the new software or the maintenance of the old system, for instance – thereby making the corresponding portfolio management decisions explicit.

You can simplify your product backlog even further by focussing on the next product version and by minimising the number of items describing future releases. As the future is uncertain and markets are likely to change, carrying many future requirements does not only bloat your product backlog; it is wasteful and makes it difficult to adapt your product to the market response. Have the courage to weed out items that are not essential to creating the next product version. Simplify, prune, and strive for order. Discarded items will come back to you if they do become relevant in the future.

A recent posting on deutschescrum brought up an interesting question: How much visioning is necessary in Scrum? Even though I find it impossible to give a general, precise and accurate answer, there are two main factors that influence the time and effort necessary to create the product vision and the initial product backlog: the product’s lifecycle stage, and its complexity.

The younger a product is, the more visioning work tends to be required. A new-product development project may spend several weeks creating the product vision and carrying out necessary prep work such as creating prototypes to explore product design and architecture options. Contrast this with an incremental upgrade of a mature product that may only require a few days of visioning work. The same applies to complexity: The more complex a product is, the more visioning time and effort is usually necessary. Note that complexity comprises not only the internals of the product – its architecture and technology – but also the functionality provided.

When determining your visioning effort, avoid two common mistakes: Don’t rush into the first sprint without having agreed on an overarching goal, without understanding what the future product will roughly look like and do. At the same token, avoid overdoing the visioning work. There is no way to guarantee that the vision is correct, that the new product or next product version will be a certain success. For anyone not blessed with perfect foresight, predicting the future correctly is notoriously difficult; no market research technique can deliver forecasts that are 100% accurate.

I therefore recommend you keep the visioning time and effort to a minimum. Do as little as possible, but as much as necessary. To find the sweet spot, try the following: First, focus on the customer needs and the three to five top features of the product. Second, envision the minimum marketable product – a product with the least amount of functionality that still has a clear value proposition. Third, quickly implement the product vision and gather customer and user feedback on early product increments to validate and refine the vision. And last but not least, reduce complexity by creating a simple product – a product that is easy to use and easy to extend and maintain.

Find out more about visioning in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.