Dealing with Negative Persuasion: Can the Product Owner Lead to Quality Destruction?

Quality: It's one of the common commercial arguments made when offering a software product. Those who have already mature products in the market justify their careers by emphasizing quality. Other companies, perhaps with more innovative products of shorter life cycle, refer to the quality of their development process and their previous successes. Others try to make quality a competitive advantage, pointing to international certifications (such as ISO 9001:2000 or climbing CMMI levels) to show their high level of quality control.

It's clear that it quality a powerful feature that has to be taken seriously. In this article I do not attempt to characterize a process of improvement, nor to summarize key points about software quality. But I will try to warn you about a situation that can deteriorate the quality of developed software.

The story starts with a product owner (PO) who looks at the product backlog and says, "Team, for the next sprint I need to develop the following user stories."

Let's analyze the sentence:

• "Team" refers to the five or so people who make up the team.
• The "next sprint" makes reference to a fixed period of time — for example, the next three weeks.
• The "the following stories" enumerates each of the user stories the PO wants completed. He is setting the scope.

Here's where the problem starts to materialize.

The Project Management Institute (PMI) states that in any project, there are three variables in game: resources (people included), time, and scope. And at the same time, these three are intimately related.

Quality is a value based on these three variables. It seems clear at first that the value of quality will be directly proportional to the time and resources involved in each sprint, and inversely proportional to the scope (dimension + complexity) of the requirements.

Accordingly, if the number of people increases in the team and more time is allocated to carry out fewer requirements per sprint, the quality of each version release will tend to improve.

Easy to say, but not very practical, is it?

In fact, quality is not always represented by the area that describes the surface of the triangle of the Triple Constraint. The model represented by the image below is wrong by several factors. The main one is that quality is inversely proportional to the volume and complexity of the requirements. Therefore an expansion thereof would induce a reduction in quality, and not an increase as suggested by the image.

Quality should actually be measured in another dimension, separated from the three variables of the Triple Constraint. In this scenario, the triangle is not a triangle any more. It is a pyramid with a triangular base; quality will now be determined by the height of the pyramid rather than by the surface of the base.

This image allows the conclusion that there may be different combinations of time, resources, and scope that can obtain the same level of quality (Q1 in the image).

So now let's go back to the situation exposed by the product owner. What the PO is doing is neither more nor less than setting time, scope, and resources (the base of the triangle) and waiting for an outcome of sufficient quality to be delivered to the customer. Perhaps what the PO requests is perfectly achievable — and perhaps not. When it is not possible, the development team has a problem. Perhaps at the end of the sprint there will be remaining user stories that aren't complete, or perhaps unit or integration tests are put aside. Intentionally or not, the PO has put the quality of the product at stake, while increasing the pressure on and decreasing the commitment of the team.

So now we have a problem. The question is how to resolve the situation — how to negotiate with the PO. There are four variables on which the team can negotiate: time, scope, resources, and quality. Which is the best choice?

Under some circumstances, the PO may be willing to sacrifice quality. But in general, as we have pointed out, quality is the most important element and therefore the last thing the PO will want to compromise. Quality goes straight at the end of the negotiating list.

A common alternative suggestion is, "We could incorporate more full-time programmers, and thus the workload of the team would be appropriate to carry out the required user stories." But to do this, first we must ask whether the user stories really can be divided among more programmers. If histories cannot be parallelized, having more staff won't be as useful as it's supposed to be. And even if the stories can be parallelized, are there training costs for newcomers who join the project? What normally happens is that external staff, coming from other teams or, worse still, from an outside source, don't know the architecture of the application or the business model. They can't be productive enough in the next sprint. If the costs and complications inherent in managing people are added to this mix, I'm confident in saying that increasing the size of the team is in the penultimate place on the list of negotiables.

Instead, perhaps the team negotiates to increase the duration of this sprint. With one more week, the team could complete all requested stories and deliver with adequate quality. Extending the duration seems not to have any harmful effect. But the problem with varying the duration of the sprint is the loss of predictability for the burn-down average. If a team has an average burn-down of 40 story points per three-week sprint, it is fallacious to think that in four weeks the team can get 60 story points. Maybe it can get close to that value, but there's no guarantee. No unusual sprint duration should be included in the calculation of the average speed of the team. So yes, modifying the duration of the sprint could be an exceptional alternative. But if it becomes common, the team burn-down will be unpredictable. The PO won't be happy with this, either.

What's left? The best recommendation is to negotiate the scope. Let the team decide the workload they're committed to deliver without negatively impacting the quality of the product or the people who make up the team.