Tag Archives: definition of done

Learning Vs Execution

Learning what a product should look like and do, and building solid, shippable software are different concerns. Separating the two aspects and distinguishing between learning and execution helps you manage the stakeholder expectations, select the right research and validation techniques, and choose the right sprint goals.

Learning vs. Execution

When we start developing a new product or new features, there are usually more unkowns than knowns, more things we don’t know than we know: We may not be clear on the user interaction, the user interface design, the product’s functionality, or the architecture and technology required to build the product. Our greatest challenge is therefore to deal with the uncertainty present, and the associated risks.

As a consequence, the early sprints should focus on creating the relevant knowledge, and addressing the key risks. Selecting a testable idea (hypothesis), and running an experiment are great ways to achieve the necessary learning. As testing ideas results not only in success but also in failure, you should expect to fail in the early sprints. Your Product Canvas or backlog, and your architecture are likely to see bigger changes driven by the newly gained insights.

As you acquire more knowledge, your focus should gradually shift from resolving uncertainty towards execution: building a product that is ready for general release. Rather than primarily testing ideas, you should now start completing features and incrementally adding new ones. Failure can still happen at this stage, but it is usually a sign that something has gone fundamentally wrong. Similarly, your Product Canvas or backlog should have started to stabilise and exhibit less volatility. The change of focus may also impact your Definition of Done: Throwaway prototypes used to test ideas quickly don’t have to have the same quality as software that will be shipped. You can now start ramping up the project, add new teams, and consider employing distributed teams.

The following picture visualises the relationship between learning and execution for the development of a new product or a new product version:

To understand how much learning and experimentation is required, consider the amount of innovation present and the technologies used: A brand-new product usually requires more experimentation than a product update; and a web app developed with standard technologies is faster and easier to create than an embedded system or a mainframe application (assuming that some market research or problem validation has already taken place).


Understanding the relationship between learning and execution has three main benefits:

First, it allows you to set and manage stakeholder expectations. It helpful for the stakeholders to understand that the early product increments are likely to be throwaway prototypes, and that failure is to be expected in the first few sprints.

Second, it helps you choose the right sprint goals, and focus the work of the development team: Your early sprints should acquire the relevant knowledge by carrying out experiments. You later sprints should build features and get the software ready for general release.

Third, it makes it easier to select the right research and validation techniques. You may want to work with user tests and product demos in your early sprints, and with releasing software to selected users in the later ones.


Innovation – creating a new product or new features – involves uncertainty and risk. To build the right product with the right features quickly, you should make a concentrated effort in your first few sprints to quickly address the key risks and acquire the relevant knowledge. Then shift your focus to completing features and adding new ones by creating software that can be released.

You can find out more about learning and execution in Scrum by attending my Certified Scrum Product Owner training course.

Please note that the product backlog board has been superseded by the Product Canvas, a new type of backlog designed for creating new products and for product updates aimed at new markets. It extends the backlog board and connects personas with the product features. Please see my post “The Product Canvas” for more information.

Most product backlogs I have come across either contain too much or too little information, ranging from literally a handful of user stories to many hundred items. Many backlogs don’t consider non-functional requirements and do not provide high priority items that are “ready” – clear, testable and feasible.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of “features, functions, technologies, enhancements, and bug fixes,” as Schwaber and Beedle (2002) write. Such a list can work well for updating an existing product. But it is often insufficient for developing a new product.

Enter the Product Backlog Board

I have therefore started to work with a structured and hierarchical product backlog, which I have named “Product Backlog Board.” Here is a sample product backlog board:

The Product Backlog Board (click to enlarge)

The product backlog board depicted above provides the following elements:

  • A prioritised story area with a ready section and a section containing themes with their epics.
  • constraint area with the global operational qualities and the critical product design and user interface requirements.
  • An optional model area that contains requirement models.

I am not the first person to recognise that flat product backlogs can be inappropriate; Jeff Patton did so a few years ago when he developed his story maps, for instance. You could even use a story map within your product backlog board if you wanted.

The Story Area

The story area is divided into two sections: items that are likely to be worked on in the next sprint, and the other outstanding work that is essential to create a successful product. The items in the ready section must be clear, feasible and testable. They are preferably captured as small and detailed user stories with well-written acceptance criteria. The epics, however, are coarse-grained and sketchy. They are placeholders for future detailed stories which are progressively derived from them. Epics are grouped into themes with each theme representing a product capability.

The stories in the ready section must be strictly prioritised, from one to n, to focus the work of the team. You don’t have to order the themes and epics unless you want to indicate when functionality will be released, for instance, in form of an early product increment (beta). But don’t forget to review the epics on a regular basis, and consider risk and uncertainty as well as dependencies. This will help you to decide how to stock the ready section and to determine which stories have to be carved out of your epics.

The Constraint Area

This area contains the global non-functional requirements of the product – operational qualities as well as product design and user interface ideas that apply to the entire product. It’s important to recognise and address these constraints: They influence the user experience, drive architecture and the technology decisions, impact the total cost of ownership and the product’s life expectancy. I prefer to capture operational qualities using constraint cards. The critical aspects of product and user interface design are best described visually as sketches or screenshots of mock-ups and prototypes. Note that the items in the constraint area are not estimated. Instead, the definition of done states that all constraints must be fulfilled. (I discuss design in more detail in my post on Agile User Interface Design.)

The Model Area

Workflows and models don’t fit into a linear, flat product backlog. Consequently, many Scrum teams ignore them. While requirements modelling should be applied lightly in an agile context, teams often benefit from connecting individual stories and epics, for instance, by showing how the user roles interact with the epics. The same is true for workflows: It’s often helpful to look at a user story sequence to understand how a user interacts with the product and to explore the resulting user experience. If requirement models and workflows are helpful to develop your product, then add a model area to the product backlog board. Like the constraint items, the models and workflows are not estimated. But they are also not included in the definition of done, as they simply elaborate stories and epics. (I describe user story sequences and workflows in more detail in my post on user story modelling.)

Making the Information Visible and Accessible

The product backlog should be visible and easily accessible for everyone involved in the development effort. I hence prefer to work with a physical product backlog board – paper cards and paper sheets put up on a large board or an office wall.

The Product Backlog Board on an Office Wall

On distributed projects the product backlog board can be easily stored as an electronic spreadsheet. Just remember to make it visible, for instance, by posting it on the project wiki.

Stocking the Product Backlog Board

I prefer to derive the contents of the product backlog board from the product vision board or the product roadmap and to focus its content on the items that are essential to develop the next product version or the next major public release. This reduces complexity, creates clarity, and avoids predicting an uncertain future.

When you stock the constraint area, resist the temptation to create the complete product and user interface design upfront. Rather focus on those aspects that significantly influence the success of the product and that are difficult to change at a later stage. The detailed design should evolve from sprint to sprint based on customer and user feedback.

“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.

User stories and use cases are powerful techniques to capture requirements. Even though Scrum is agnostic about how requirements are described, user stories are becoming the standard way to express functional requirements on the product backlog. Before I explain why, let’s briefly reflect on what user stories and use cases have in common.

Both techniques put the customer or user at the center of the development effort. Use cases describe how a customer interacts with the product using one or more scenarios. A use case may consist of a short narrative or of several structured scenarios including main success scenario, alternative scenarios and failure scenarios. User stories describe how a customer or user employs the product. Stories consist of a name, a brief narrative (the story) and a set of acceptance criteria. The latter formulate conditions that must hold true thereby making the story more precise. Uses cases and user stories employ customer roles known as primary actors and user roles respectively. Both techniques can be applied at different levels of granularity: Use cases may be written as business or system level use cases. User stories may be formulated as epics, coarse-grained or detailed stories.

User stories are particularly popular on the product backlog for two main reasons: First, applying the technique is easy (but writing good stories can be hard). There are no complicated templates, no pre and post conditions, no triggers and exceptions to be specified. Since the barrier for writing stories is low, it’s easy to do it together involving the entire Scrum team. Second, decomposing stories is comparatively easy; large stories or epics are broken into smaller, more detailed ones over time to ensure that they can be delivered within a sprint according to the definition of done. Having worked with both user stories and uses cases in Scrum, I do prefer stories over use cases on the product backlog.

If you like to work with business use cases to create the product vision, then derive user stories from your use cases by splitting each use case scenario into one or more stories. The stories are then used to stock the product backlog. And don’t feel obliged to describe every single product backlog item as a user story. User experience requirements, for instance, are best captured using different techniques such as user sketches, storyboards, user interface navigation diagrams, and prototypes. These artifacts complement and elaborate the stories on the product backlog.

You can learn more about stories on the product backlog in my book Agile Product Management with Scrum or by attending one of my upcoming product owner classes.

Software quality is often perceived as something the nerds should worry about. But it significantly impacts product success by affecting the following areas: customer satisfaction and brand value; the total cost of ownership and life expectancy of your product; and the product’s competitiveness as I explain below.

Why Quality Matters

Quality influences customer satisfaction and brand value. Only if the product’s functionality works reliably as expected will customers be satisfied and value the brand highly. Defective software does not only leave customers dissatisfied, frustrated or angry, it also damages the brand value. Think about the issues Microsoft experienced with Windows Vista. These contributed customers defecting Microsoft and to the company to discontinuing the Vista brand calling its next OS version “Windows 7.”

Quality impacts the total cost of ownership and life expectancy of a product. Getting software out of the door quickly with poor quality may achieve a short-term win but it incurs technical debt: The software becomes difficult to extend and maintain, as Ward Cunningham observed nearly two decades ago. This results in high cost and long lead times for new functionality. And software with poor quality often has to be replaced sooner rather then later resulting in a short life expectancy and a poor return on investment.

Quality affects the product’s competitiveness: To create a product that incorporates customer feedback on early product increment, to release software in response to the latest market development, and to bring new functionality to the market quickly is only possible if the product exhibits the right quality. Take the development of Google News, an application that aggregates news from around the world. Google used user feedback on early versions of the software and user requests for new features to determine which functionality the product should contain.

Compromising software quality means trading in short-term gains for longer-term growth cheating the company of a better, brighter future. As the product owner, you are first and foremost responsible for product success. Software quality should hence be a concern to you.

What Product Owners can do to Ensure Right Quality

There are many ways for a product owner to help get the software quality right:

Think products, not projects: A product owner should own a product and look after it for an extended period of time thereby managing the product’s lifecycle. A longer-term responsibility counteracts the temptation to compromise quality in order to get the next release out as soon as possible. It creates a desire for sustained success and it encourages long-term thinking.

Create a common understanding of quality. Make sure that a definition of done is available and apply it properly. The definition should clearly state the general quality criteria product increments must fulfil. It usually requires that a (potentially) shippable product increment is available at the end of each sprint: executable software that has been tested and documented and that could be released. As a consequence, quality assurance and control measures form an integral part of the development work—instead of being carried out at the end of the project as an afterthought. Be specific what tested and documented mean for your product; I have worked with teams that used metrics to refine and measure the quality criteria. As the product owner, you have to apply the done criteria to accept or reject work results when reviewing items; only work results that fulfil all the done criteria can be accepted. By enforcing the definition of done the product owner acts as the guardian of quality.

Minimise defects and unnecessary rework. Groom the product backlog together with the team and by be available to answer questions as they arise. With requirements emerging and changing, the product backlog needs continued attention and care. New items have to be captured, existing ones adjusted or removed. Items have to be prioritised and estimated; and the high-priority items have to be ready for the next sprint planning meeting. User stories likely to be implemented in the next sprint should now have well-formed acceptance criteria, for instance. Jointly grooming the product backlog ensures that it contains the right items in the right order. It also reduces the likelihood that an items implementation differs from how the product owner intended it to be realised. When it comes to product owner availability, I often suggest the one-hour rule: Product owners should spend at least one hour per day on average with their teams in the same room. This ensures that the product owner is available to answer questions and to provide feedback on work results.

Invest in quality: Product owners must understand that team members need time to create high-quality software and regard agile development practices like test-driven development and continuous integration as a great way to ensure sustained product health. Setting aside time for team members to experiment with new practices and tools may result a lower velocity in the short term, but it speeds up development in the mid to long-term.

Be clear on the difference between fidelity and quality. The product’s functionality evolves, and its fidelity may well increase during the project; the look and feel and the overall user experience might improve. But the software quality – as defined in the definition of done – should stay constant throughout.

Find out more about the product owner’s role in creating great products in my book Agile Product Management with Scrum, or attend one of my upcoming product owner classes.