Why Product Owners should Care about Quality

Software quality is often perceived as something the nerds should worry about. But it can significantly impact customer satisfaction and brand value; the total cost of ownership and life expectancy of your product; and the product’s competitiveness. This post explains what product owners can do to help their development teams get quality right.

Why Quality Matters

Quality influences customer satisfaction and brand value.It’s like drinking coffee. Who wants bad-tasting or strange looking cup? 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

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.