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

31 January 2012

Fernando Serrano
Instituto Zaldivar

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.


Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.



Article Rating

Current rating: 0 (0 ratings)

Comments

Gagan Rana, CSM,CSPO, 2/3/2012 8:04:36 AM
I agree, negotiating scope is the best option in above scenerio. However, I have seen where new contract developers were brought in the scrum team to ensure we don't miss the delivery date. Of course, we have given appropriate learning time to new developer to get upto speed.
Andreea TOMOIAGA, CSM, 2/15/2012 6:56:01 AM
Hi Fernando, this article is very interesting in my opinion. I agree with the conclusion on negotiation on the scope dimension and also would like to add an aspect relevant to this scope negotiation in my opinion. Especially in new product development in competitive markets, catching the opportunity window is very important so basically in order to get the business advantage this has to happen "on time". So time should not be a moving target. Since time is fixed and other relaxation on the other constraints are not recommended, scope would be the single negotiable dimension - and this negotiation should be based on a conscious prioritization of the PBIs - in order to ensure that items that would really make a difference on the market at that time are not left out.
Randall Schmidt, CSP,CSM, 2/15/2012 3:21:11 PM
Some would also build a non-PMP triangle in software development circles, and believing in self-managment to take care of the resources issue that the three main varibles are: Time - Features - Quality - and again a flat 2D triangle falls short of explaining the total picture.
Fernando Serrano, CSM, 2/15/2012 8:22:58 PM
I agree with your opinions in special when you have a time market challenge to get a competitive advantage. If you are in this kind of situation, then make sense fixing the rest for reaching the first place in the market.
It always depends of each company, but I think if you use this strategy as general criteria, you are going to fall in trouble in the medium-long term.
Thanks for reading and thanks for comments.
Jennifer Lynn Vanderputten, CSM, 2/23/2012 10:51:17 AM
To add my vote to the article and comments about scope, this is such an important aspect. As mentioned, when market timing is critical, as it is for so many of us, scope is the real issue being discussed. The single point that I've been working on with my product owner is the idea of value and scope. The revelation came to me when I worked on a scrum team for short term project. Since this was a partnership project, we could do more frequent releases than we usually did for our larger scale projects. I kept thinking, there's no value until all the stories on this backlog are done. After the first sprint, we gave our partner a build with the handful of stories we had completed. They were ecstatic. There was something of great value that they could use right away. Each sprint we released the next build and their excitement and appreciation grew.

You must Login or Signup to comment.