How to ensure sprint tasks are bug free before release

Question

I was asked this question in an interview, and couldn't figure out the solution, so I thought I will come here.

Basically, I was mostly working as a developer, and had my own set of unit tests for the tasks I was finishing. But if I was a product owner or scrum master, then how will I ensure that development team has created enough unit tests, or tested the code properly?

I think we can have acceptance testing, or even consider the bugs as part of next sprint. There is another option of having product owner and scrum master create a set of basic tests during sprint meetings. But that will cause the sprint meeting to run for hours. These are the two possible ideas that I could suggest.

Is there any other way, a product owner can ensure the quality?

Answer 1

TL;DR

The enforcement of the Definition of Done (DoD) is the Product Owner's primary mechanism for ensuring product quality. The DoD defines quality for the project. Ensuring that work that falls short of the DoD is returned to the Product Backlog is the project control for preventing known defects from escaping the Sprint.

NB: Because the team's capacity is finite, the Product Owner controls quality by trading off capacity for explicit backlog items and implicit tasks associated with the DoD.

Manage Quality with "Definition of Done"

In agile frameworks, the way you manage quality is through the "Definition of Done." This is a formal definition of all the quality gates that a potentially-shippable increment must pass through to be considered done at the end of a Sprint. Because Scrum requires that the product always be in a potentially-releasable state at the end of every Sprint, the DoD also includes acceptance tests, regression tests, and other quality criteria to validate that the product itself (and not just the current work increment) meets the defined quality criteria.

Because work is either done or not-done at the end of each Sprint, work that doesn't meet the DoD is considered "not done" and must be returned to the Product Backlog for reprioritization and replanning. Partially-complete Product Backlog Items are never considered done, and are never automatically carried forward. This is a key control for the Scrum framework.

Because Scrum is an iterative framework, the DoD may evolve over time. The Product Owner can fine-tune the quality of the product by working with the rest of the Scrum Team to determine the extent and granularity of the DoD based on lessons learned and information gleaned from the Sprint Retrospectives.

Trade-Offs in Quality

A team with a very complex or time-consuming DoD will need to reduce its capacity forecasts accordingly, as more team capacity is directed to getting work increments to "done." On the other hand, increasing feature development at the expense of an adequate DoD may result in tech debt or an increased defect rate, which can also reduce the velocity of feature development.

NB: Velocity of work is not reduced, as defect management is also work.

In short, the Product Owner and Scrum Team need to find a DoD that is sufficient but not excessive. Too much process overhead, and feature development suffers. Too little, and quality suffers. It's a balancing act, which is why there's no such thing as a universal standard for the Definition of Done.

Answer 2

This question does not have to be agile oriented but rather can be answered in an agnostic way because it affects all methods, products, and industries the same way.

The answer is: you cannot ensure a defect-free release of your product.

Both of those italicized words imply a degree of perfection that is unavailable to us.

Instead, you mitigate the threat of defects through inspection to drive the level of defects to both a quantity and severity that are within a defined level of specification.

This means the governing body needs to create that definition of specification for the product as part of the definition of the project during initiation and it means defining what inspection means based on your industry.

It also means you mitigate the threat of defects proactively, by maturing your build processes and methods, using proven tools, using skilled talent, and using metrics to measure performance. Metrics can expose an increasing threat of defects even before a defect is noticed in the product later in the process.

Answer 3

The critical role a Product Owner has in ensuring quality is often overlooked.

There are a number of factors at play, including:

• How do you know the new functionality added in the sprint has been tested?
• How do you know the tests are fit for purpose?
• How much regression testing has taken place?
• Are there any known gaps in test coverage?

The Product Owner contributes to all these factors by doing the following:

• Emphasising the importance of quality and of the team meeting their definition of done
• Never asking the team to deliver more functionality in a sprint than they have the capacity for
• Working closely with the team to ensure there is a close relationship between requirements and tests (possibly using a technique like BDD)
• Weighing up the pro's and con's of gaps in test coverage (such as the extent of cross-browser testing, or how much non-functional testing has been completed)
• Ensuring they are sufficiently available to the team to answer any questions on the requirements