Tag Archives: software quality

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.

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.