The difficulties of dealing with technical requirements in Scrum
In agile transformation projects, the position and scope of the Product Owner role is often source of confusion. Most agilists get that it is about translating user wishes into stories. Functionally it seems OK (thus it is not always easy to do). But a software product is more than a bunch of features.
If you have seen conflicts between the Product Owner and the development team about a technical change (refactoring, framework updates are common ones), you are at the right place. In this article we will propose a review of what the role of PO consists in with a focus on technical aspects. We discuss then how it impacts the staffing for this position.
All Scrum practitioners know that the PO is in charge of maintaining the product backlog. It includes defining the functional solutions to answer the customer needs. The Product Backlog Items (PBI), often called stories, are designed vertically so that each of them brings value. They are arranged by priorities in the product backlog.
When we describe the PO role, the first answer is that the PO has to understand the customer needs and drag from it the actual functionalities that the product team should develop. The PO incarnates here the customer and transform its needs into small chunks that brings each a piece of value.
This is absolutely correct yet incomplete. The tendency to see only this part of the role is the root of the issue faced with technical developments.
What is a product?
Scrum methodology makes an extensive use of the word “product”. It does not give any detail on what the word encompasses. In fact it will vastly depend on the context in which Scrum is used.
For the sake of defining the boundaries of the Product Owner role, it may however be of some help reviewing what a product can be.
Limiting ourselves to software, we can already have a wild variety of product size and complexity. Let’s present few examples:
- A mobile application executing basic functions like a hangman game
- A mobile application executing basic functions, and connected to several backends to ensure communication and data persistence like a messaging system
- A library executing a rather simple set of functions like a logger or a connector
- A library executing complex functions like facial recognition or a video game graphical engine
- A service of low functional complexity like a basic e-commerce site
- The same service but scaled to the extreme and running on thousands of nodes with failover
- A complex framework handling complex use cases like an application server
- A distributed system offering sophisticated services like a Global Distribution System
Obviously, if all these type of software systems answer functional needs, the technical complexity of each is hugely varying. The importance of technical knowledge at Product Owner level varies with it.
All in all, a product is not only a set of functionalities but a software artifact with many characteristics like performance, security, portability, extensibility, etc. This may or may not be a major concern for the PO depending on the very nature of the product itself, but it sure requires to be assessed.
Back to responsibilities in Scrum
The development team is responsible for proposing a product increment fulfilling predefined done criteria. It covers any aspects of the software, both functional and non-functional.
The PO has to express the needs, including non-functional aspects, and accepting the increments, i.e. to understand how the team addressed these points.
The technical aspects can come in two flavors: as acceptance criteria of stories or as standalone stories.
Non-functional acceptance criteria
A software artefact is more than a bunch functionality. Depending on the business environment you are in, the constraints will be different. But if a feature increases by 200% the memory consumption of Google search Engine, I doubt it will reach Google production servers.
The Product Owner is in charge of writing product backlog items. It includes writing technical acceptance criteria (response time, memory footprint, deployability..., the list is long). As with any criteria, this is a subject that can be discussed with all stakeholders, included the development team itself. But all in all the PO is accountable for it.
Back to the different type of products, it can clearly see that the frequency to which the PO has to work on these acceptance criteria will vary a lot.
This is the most common case of issues: the development team wants to rewrite a part of the product, independently of any functional stories. And the PO does not accept it. In some cases a story is written but never prioritize in a way to allow an implementation.
First, let's evacuate a common misunderstanding: a story is not necessarily functional. The backlog contains Product Backlog Items that can very well be technical. However, a PBI must have a business value, including the technical ones. An example of technical story is the setup of a branching model, hopefully compatible with Scrum. We discuss about this topic in this article.
And there is the difficult but necessary part: assessing the business value of a technical story. It means that the request of this story (usually the development team) must explain the proposed technical change by its justification (the WHY) and not by its content (the WHAT). By experience it is very difficult and may lead to challenge the fundamentals of developers's ways, yet it has to be done.
You propose to migrate from JBoss 7 to Wildfly 10? Why?
You propose to refactor the payment module? Why?
You propose to deploy via Docker containers? Why?
They are good reasons to do these three things. We could imagine discussions around continued support from the community, speed of integration of new payment providers or ease of deployment. But they have to be valued against features asked by the users.
Again collaboration is probable and wishable, but if the PO is fully hermetic to any form of technical discussions, it will be virtually impossible to get anything done.
Skills: who could become Product Owner
We see around many agile transformation with very different results. A usual source of issues is the appointment of the Product Owner in the newly formed organization.
As you might have guessed, there is no unique way to select a PO. It does depend a lot on the product but as well on the company context, the support the PO could get from its organization and how impacting it could be if he needs to answer team’ questions with a delay…
As far as the technical subjects are concerned, it is important that the technical skills of the PO are aligned with the technicality, complexity and ambition of the product. These three axes will define how much technical stories and non-functional acceptance criteria will show up.
In any case it can be difficult to get rid of the habits acquired in one position when taking a Product Owner role. And this is one of the reason to avoid “Scrum, but”: if a PO goes beyond or below the expected scope of its position, it can damage the organization a great deal.
The role of the Product Owner in Scrum is absolutely critical. If a member of the development team can be challenged rather quickly by its peers during ceremonies, the effects of a poorly chosen PO are not immediately visible and often extremely harmful.
And no, in most cases a good relationship with customers and management is not enough to be a good PO.