The universe of the product owner
This is an originally german article, translated with DeepL, but with the original german-labeled images.
Very often (especially in Scrum-heavy literature) the work of the product owner is equated with the maintenance of the product backlog. req42 goes clearly beyond this.
Agile requirements engineering is much more than just managing the product backlog.
Of course, the product backlog is the most important artifact for managing requirements in agile teams. However, it is often overlooked that as a product owner you also have to take care of other things. For example, you should have written goals so that not everyone in the project dreams of other goals. Of course, everyone should speak a common language, because if everyone talks about different things, then there is a big risk of communication problems in the team.
To show you as a product owner the totality of the things (new German: Artifacts) you have to manage, we have chosen the universe as a metaphor, or better the part of the universe that concerns you as a product owner. At the center of your universe is the Product Backlog as one of your most important working tools. However, many other artifacts that make agile requirements engineering successful revolve around this center (see Fig. 1).
Not a document, but simply ordered knowledge.
We hope this metaphor gets you away from the idea that you need to manage all these artifacts in the form of a document. You should just have these artifacts tangible in some form that allows all stakeholders involved to communicate about them in a reasonable way.
Remember our color code we introduced on www.req42.de? If not - as a refresher again: red are the things of your universe that are mainly management oriented, blue are the requirements relevant things and green are the results of the development team.
As a product owner you are a mix of manager and business analyst/requirements engineer, so your universe consists mainly of red and blue planets.
1 - The
Product Backlog:
The Scrum Guide [1] defines: “The Product Backlog is an ordered list of everything that is known to be included in the product. It serves as the single source of requirements for all changes to the product. The Product Owner is responsible for the Product Backlog, its contents, access to it, and the order in which entries are made.
A product backlog is never complete. During its first development steps, it shows the initially known and best understood requirements. The Product Backlog evolves with the product and its use. It is dynamic; it constantly adapts to clarify for the product what it needs to be adequate to its task, to compete, and to provide the required benefits.”
As long as a product exists, so does its Product Backlog.
So you see: the Product Backlog is really important for successful work as a Product Owner. But please read on. Your job may not start with the Product Backlog and it certainly doesn’t end with the Product Backlog.
2 - The result of the iterations:
Product Increments
The product increments are generated by the development team. For IT systems, these increments should be “potentially deliverable subsystems” with all the trimmings (documentation, release notes, installation instructions, …).
The task of the product owner is to approve these intermediate results at the end of each iteration, i.e., to assess whether the requirements that were to be implemented during this period were actually completed (according to the Definition of Done - DoD).
If not, new requirements may have to be added to the Product Backlog.
3 -
The management-oriented artifacts
As a product owner, you are responsible not only for continuously providing your development team with requirements, but also for goal alignment, planning, continuous value and risk management, and prioritization. All of this, of course, while making the best use of the resources (“assets”) you are given to do so.
So, in addition to the product backlog, you will also be managing a range of information, which we would like to introduce to you in the following paragraphs.
3.1 -
Assets
Under “assets” we summarize what your clients or bosses give you to enable you as a product owner (together with your team) to do your job successfully.
Assets definitely include time and budget, i.e. resources that you are given to do your job. You may have to get your team with these resources yourself, or they may also provide you with staff (your team), workspace, infrastructure, etc.
If you take the job as a product owner, then you will have to negotiate about these assets with your clients and certainly in the end you will have to account for their use as well (through hopefully successful results).
In any case, you should know what you have at your disposal in terms of money, personnel, time, infrastructure, …. These assets are an essential boundary condition for your work as a product owner.
3.2 -
Business Goals
Perhaps your clients gave you rough goals or a vision when they entrusted you with the role of product owner. However, the precision of these specifications is often not enough to systematically lead a team to success.
It is part of your job to specify and agree on the goals to such an extent that everyone involved has a clear idea of what is to be achieved and within what timeframe.
For us, goals are requirements! Or more precisely: goals are requirements, which hopefully do not change continuously in the period for which they are defined.
For the definition of goals we show you several variants in our trainings (PAM, product case, news from the future, product canvas, value propositions, …), which you can choose according to your mood. There is only one thing you should never do: work without explicit goals or visions.
3.3 -
Roadmaps
Agile projects also need a plan. The more distant a goal is, the less precise the plan can be. The closer, the more precise.
An explicitly known roadmap enables everyone involved to think in the medium term and therefore take into account what is still to come when making short-term decisions. If you are just living from hand to mouth, you may unknowingly make short-term decisions that are contrary to longer-term product success. In our courses we show you how rough or fine a roadmap can, may or should be.
3.4 -
Teams
If you have more than one team at your disposal, it goes without saying that you should have an overview of who works in which (sub-)team and how these teams are organized. Basically, today you should not disregard “Conway’s Law”. The team structure (i.e. your organizational structure) and the product structure should not contradict each other, otherwise a single sub-team cannot deliver meaningful results without having to constantly coordinate with all the others.
You can learn more about the art of sensible division into sub-teams and their coordination in the section “Scaling” and “Scaling Frameworks” in our courses.
3.5 -
Risks/Assumptions
Risk management is project management for adults” says Tim Lister of the Atlantic Systems Guild. In this sense, you should keep your risks under control as a product owner.
req42 provides you with the means to consciously manage risks. Especially when prioritizing your requirements, you should balance business value and risk reduction.
4 -
Other requirements-oriented artifacts
In addition to the management-oriented artifacts and the central product backlog, it is worthwhile for you as a product owner to have up to six other artifacts constantly under control.
4.1 -
Stakeholders
Stakeholders are your most important sources for requirements. Therefore, you should know them and make them transparent (in the form of stakeholder lists or stakeholder maps). You need to know who of them can help you with what or hinder you in what way. You need to know who has what influence - and in the case of differing opinions, you need to mediate or decide.
Without explicitly identified stakeholders, all this is difficult.
4.2 -
Scope delimitation
Scope is the area that you can influence. This is in contrast to your environment (“context”), with which you certainly have many interfaces, but which you (usually) cannot decide on your own, but often have to negotiate.
There are many different means of expression for representing scope delimitation, but a good scope delimitation makes the interfaces to the context explicit (e.g. in the form of inputs and outputs, of services offered and required, …).
req42 recommends starting with the business scope and not limiting the product scope too early. The decision about the product scope should be a conscious decision.
Read more about this indispensable topic in the blog post “Scope is not equal to scope” or in [2]. In our courses, you practice scope delineation using a realistic case study. Or we do it together with you using your products in the form of impulse workshops.
4.3 -
Quality Requirements
Our experience shows: Quality requirements are (unfortunately) still severely underestimated, not only in the agile world. Everyone wants good quality products and services, but only a few make it explicit what exactly is meant by this.
Some quality requirements (like response times) might be written directly to a story. However, the vast majority of quality requirements relate to many cards, if not all of the cards in the product backlog. Therefore, as a product owner, you need somewhere to specify the desired qualities of your products and services.
We show you (with industry-proven checklists) how you can quickly identify the most important of these and manage them in the medium term in the form of quality trees with scenarios.
4.4 -
Constraints
(Technological and organizational) constraints are also requirements. And since they often apply to several or even all functional requirements, they are difficult to accommodate in the ordered product backlog. Just make sure that all stakeholders know these constraints and have access to them when needed.
4.5 -
Domain Terminology
Terms from your domain appear in every epic, feature, or story. These terms should be clear to everyone involved. And that’s why it’s desirable to have a glossary of such terms for a project or product development. Make sure that everyone involved speaks a common language - and has access to agreed-upon definitions of terms when in doubt, instead of bringing new words into play in every meeting.
4.6 -
Supporting Models
In the agile world, it has become widespread to write requirements in the form of epics, features or stories on little cards (or to file them in equivalent form in tools like JIRA).
Nevertheless, communication among all stakeholders sometimes becomes significantly easier if you also use the tools we have come to know over the last decades to make the colloquial language more precise. So don’t be afraid to use sketches of flowcharts, activity diagrams, BPMN, state models, data models, UI prototypes, mock-ups, … if it helps communication.
Don’t worry: these models don’t have to be perfect. But sometimes a graphical visualization of the 15 steps of a business process promotes understanding better than 15 cards.
Summary:
req42 gives you many degrees of freedom, with which methods you should create these artifacts, which notations you use for communication and how you can perhaps manage the results tool-supported. But one thing should be clear to you as a product owner: You do not only work with the product backlog!
Literature:
[1] Schwaber, K., Sutherland, J.: Der Scrum Guide, November 2017, www.scrumguide.org
[2] Hruschka, P., Starke, G.: Scope ist nicht gleich Scope, Java-Magazin 4/2019