The Developers are responsible for determining the costs of realizing a Product Backlog Item

22 January 2020 Fact Myth or Fact

Fact

“Scrum is a framework for developing, delivering, and sustaining complex products” (guide). In this first sentence of the official Scrum Guide lies the first clue as to whether the above statement is Myth or Fact; what is actually meant by complex products?

Complexity

The industrial revolution saw not only an increase in the amount of wealth but also the invention of a new organization of work known as the factory system, which entailed increased division of labour and specialization of function. It is in this period that we also see the advent of scientific management (Taylor, 1911), in which one of a manager’s primary goals was to determine the best way for the worker to do the job (Britannica, 2020).

Women working machines at the American Woolen Company, Boston, c. 1912.
Library of Congress, Washington, D.C.

Although this period in history was certainly revolutionary, the factory system itself can be characterized as repetitive, standardized and capital-intensive. Time-and-motion-studies were developed and employees were expected to fulfill tasks in a predescribed way. Customer preferences hardly changed compared to nowadays, or were not allowed to as illustrated by the famous quote by Henry Ford; “any customer can have a car painted any color that he wants so long as it is black” (Ford, 1922).

When you look at the famous Stacey matrix (Stacey, 2002), this period in history can be characterized as a simple environment for most employees; requirements hardly change, and the technology used is certain. This allows for long-term-planning or waterfall.

Stacey Matrix - Product Complexity
Stacey Matrix

Today most work in software has shifted towards the complex domain. The development of globalization, digitization, and speed of innovation means that technology has never developed quicker than it does today. At the same time requirements never seem certain due to the speed of changing customer preferences and disrupting business models.

Scrum is a framework that outperforms predictive methods, such as scientific management or waterfall, in this complex domain because it uses empirical process control (Latre, 2019). Complex work requires creativity as answers are not readily available. Collaboration and experimentation become more important. Even outcomes aren’t predetermined. In other words, as work is no longer standardized, only those that perform the work are able to make any sort of estimate concerning the work.

Costs

But how does all this relate to costs? The Scrum Guide mentions the word “cost” only once when it discusses that the Sprint itself limits risk to one calendar month of cost. But that doesn’t really help us; it means all Product Backlog Items that are deemed ready for selection in Sprint Planning do not cost more than what it costs to run a Sprint.

The Scrum Guide mentions the word “cost” only once

So far it also doesn’t allow us to distinguish between Product Backlog Items. And can costs really be determined upfront? The word “determine” sounds pretty definitive! Didn’t agile practices emerge because our waterfall planning proved to be useless in complex environments?

Framework

So how to proceed from here? Let’s focus on the framework. The Scrum Guide states that the Scrum framework is designed to deliver products of the highest possible value. It also states that “the Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team” (guide). For the Product Owner to be able to decide what Product Backlog Items will maximize the value, he or she has to take into account what it will cost to deliver these items. 

The Development Team is responsible for all estimates

Scrum Guide

We already concluded that Scrum is a framework that is suited for complex work. We also concluded that in this domain the best estimates are made by those that perform the actual work. The Scrum Guide agrees and is very clear on this: “The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.”

Refinement

So how and when does this estimation take place? “Product Backlog Refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items” (guide).

Usually, the development team makes an estimate relative to one or more reference Product Backlog Items, and based on the past performance of the team this provides enough information for the Product Owner. Often teams use concepts such as story points or t-shirt sizes. As Product Backlog Items are broken down to a size that fits into a Sprint before they are considered to be selected for a Sprint, the above-described estimates usually provide enough detail. As a safeguard, there is always the Sprint which maximizes the amount of time a Development Team will work on a Product Backlog Item. 

Conclusion

Should Development Teams determine the exact monetary costs of Product Backlog Items? Probably not. The more precise this estimate required, the bigger the chance of it being wrong. Usually, the cost of running a Sprint is treated as a constant by the organization, and the above-described methodology is sufficient. However, this does not mean that the responsibility for estimation does not lie with the Development Team. In conclusion, the statement “The Development Team is responsible for determining the costs of realizing a Product Backlog Item” is a FACT.

Bibliograpy

Recent Comments