Boost your backlog – Part 1

10 practical tips for product owners and those who want to become one

Many product owners start to create their first stories or PBIs (Product Backlog Items) against such a background, but the daily work in and on backlogs is not as easy as the 20-page Scrum-Guide might suggest. The good news is that you are not alone with this experience, and we are dealing with solvable problems through the bank. This article brings together ten – admittedly subjectively selected – solutions and techniques that have repeatedly helped product owners and agile teams in coaching. As the title suggests, it focuses on the product backlog and deliberately hides other topics such as the product vision or the “big picture” of agile requirements engineering. (If you would like to learn more about this, you will find details in [1] and [2]).

The collected 10 practical tips can be roughly divided into the three thematic blocks “Finding stories”, “Writing stories” and “Improving stories”. They are of different size and have different concrete contents, but each tip was chosen because it can be useful for you when creating and maintaining a backlog. The very first one provides above all for basic understanding and probably seems to you to be less operative, but this will change from the 2nd “Boost” at the latest. (And one last note before we start: Most tips are explained using the example of Scrum, as this is still the “Tempo among agile tissues”, i.e. the most widely used agile framework in IT projects).

1. Boost: User stories are not requirements

There is a widespread misunderstanding that other authors have already pointed out (see for example [3]): User stories are work packages, i.e. planning artefacts that have an extremely meaningful name and ideally testable acceptance criteria. They therefore do not play the role of “requirements” at all! Rather, you should think of stories as “containers”, whose name alone – i.e. the “story” in the well-known format with role, functionality and value – does not contain all the details that the agile team needs for processing, and which therefore need to be “filled” and enriched with details. This is mainly done through direct communication in the sprint, but this is not always sufficient or the best possible solution. So please do not give in to the image that the IT discipline of “requirements engineering” has been completely replaced by “stories on a board”! Freely adapted from Frank Zappa, the only thing that applies in Agile is: “RE is not dead, it just smells funny”. [4]

In other words: stories name a requirement, but they do not describe it. The story template addresses the “what” and the “why” of a customer requirement (the so-called problem space, see Boost 3), but does not provide any further details. It only helps the team to understand the work package faster and better at a glance. A work planning using stories does not release an agile team from all tasks of requirements engineering and documentation!

Once you have internalised this fundamentally important message about user stories, you are prepared for more. But first a little patience please. (You will get further tips on acceptance criteria in Boost 5 and on story specifications in Boost 6).

2. Boost: How you can systematically find stories with Use Cases & Story Maps

Use case modelling, a central tool in object-oriented analysis, may look a bit outdated, but despite its venerable age, it has shown that as a product owner you can use it to quickly, easily and systematically develop a first load of user stories (more precisely: “epics“, i.e. big stories) for your initial backlog.

In practice, a wall/whiteboard/flipchart and some time with customer representatives and stakeholders is sufficient for this. An elementary use case diagram describes the outside view of the targeted product, i.e. a black box view from the user’s perspective, and provides an answer to the question: “Who gets what from the product? This provides an initial partitioning of the product along functions to be developed for specific user groups.

In the diagram, the user groups are called “actors” and the identified functions are called “use cases”, which – hold on! – are characterised by the fact that they are accompanied by a business value for the user. (If you know user stories, you should have a déja-vu now.) Experience shows that a moderated first workshop in front of the above-mentioned wall leads to stakeholders agreeing on roles, designations and functions; this does not take long and is helpful for the subsequent course of the project. As an aside, use cases therefore also provide a practical tool for creating a product vision.

Good use cases have a verb in their name (i.e. “order a book”) and are connected via a simple line to the actors who are allowed to trigger the use case. And that’s it: Every combination of actor and use case can be transferred almost mechanically into the story format (only the business value – which by definition should exist for every use case! – must still be explicitly added), and thus you receive the first valuable PBIs for your backlog. They are usually quite coarse-grained and therefore too large for a single sprint, so we usually treat them as epics.

And then what? Well, then Story Maps are a great help.

One after the other: In traditional analysis, identified use cases are specified in the next step in such a way that the internal processes are described that are necessary to achieve the desired result. These processes are often subdivided into “normal process / happy path”, “alternative processes”, “error handling” or similar. If you now describe a normal process as a sequence of process steps for each Use Case (=Epic) and then collect for each process step what the product can/needs to provide, you have a “Story Map” according to Jeff Patton ([5]). And with it a whole lot more stories for your backlog! An example of such a map can be seen in figure 2: Simply replace “1st activity” with “Use Case”, consider the steps marked in yellow as process modelling of a procedure/scenario for this Use Case, and the “detail functions” are then story candidates.

Figure 2: Example of a story map (from [6])

For details, refer to [5] and [6]. The described procedure works excellently in practice, supports you in topics such as MVP or release planning, and of course it can be applied in the same way to other identified processes/scenarios per use case. Give it a try!

3. Boost: User stories stay in the problem zone!

In the problem zone we describe the “what” (the customer wants) and the “why” (the customer wants something), but not yet the “how”, i.e. the technical implementation – this is then part of the so-called solution zone. Admittedly, the border between the two is not always clearly recognised, but you should try not to lose sight of it. User stories of the flavour “As a user I would like to have another button next to the input field <XYZ>, with which I…”, which stay in the solution area (“button” in a user story? More solution area is not possible!), should be avoided in the backlog if possible. Why?

The development of a technical solution for a technical request is the responsibility of the development team. Whenever your stakeholders already come around the corner with technical solutions – however obvious and tempting they may seem – several follow-up questions arise:

• Who says this is the “best” technical solution?
• Why does the creative and technical potential of the team remain unused?
• And perhaps the “solution” anticipated in the story is technically not feasible at all or endangers specifications for user guidance, accessibility, etc.?

Specialists are usually not technical experts, and one of the tasks of a product owner is to mediate between these two worlds.

A tip: If a stakeholder is already on the road with solution ideas, feel free to take their solution as an “example” for the team (because it may help the team to better understand what the customer needs), but point out that there is no guarantee that exactly this solution will be built and that the development team may come up with even better suggestions. Also, do some re-drilling: For example, why does the stakeholder want this button? The “5-Whys” technique says that you have to ask “Why?” a maximum of 5 times until you have the actual technical “need” of the customer in front of you. And you then cast exactly this “need” into a story!

Perhaps the following thought experiment will help: Let us explain to you how the desired thing would look in a pre-IT world, e.g. paper-based, where there are no clicks, Excel exports and apps yet. The goal for a PO should be to be able to navigate in the language of the domain (i.e. “create new customer” instead of “click on <XYZ>”). Separate business and implementation wherever possible!

Footnote: By the way, if you sometimes find it difficult to specify the role in the story template, you and your team should experiment with “job stories” [7]. But they also stay in the problem zone.

4. Boost: Avoid “technical stories”!

Let’s stay a little bit on the borderline between professionalism and technology. You can recognise “technical user stories” by the fact that the role is not a user, but a project member or even an IT component. For example:

• “As a tester I would like to…”
• “As a developer, I would like…”
• “For the back end, I would like to…”
• “As an API, I would like…” (one of my favourites)

Furthermore – you guessed it – these stories move almost exclusively in the solution space (see Boost 3).

Behind this is often simply the misunderstanding that, as a result of an agile transition, all wishes and requirements must be available in the story format. Or your project, which consists of several agile teams, is organised in so-called “component teams”, i.e. along the architecture of the product (e.g. a UI team, a backend team, a storage team, a team for component X etc.). In such constellations, of course, not every team has direct “contact” with the technical domain and the wishes of the user, and if such a team wants to fill its own backlog with stories, experience shows that the proportion of technical stories increases. (Marginal note: If still possible, in such a situation it is better to think about “feature teams” [8] and fight the causes instead of the symptoms).

In practice, technical stories regularly cause the PO to have problems prioritising them or naming their “business value”. No wonder, because the “value” of these stories almost always consists of the promise of higher team velocity in the future. Also, formulating acceptance criteria and answering team queries during the sprint can be tricky for the PO in technical stories.

Technical tasks, such as expanding the test automation framework or code refactorings, must of course be planned and priced in by the team in a sprint – but there are other solutions than pressing tasks into story format and thus abusing the format of a “user(!) story”. Most often, tasks work instead – i.e. technical tasks that are the responsibility of the team and are collected in the sprint backlog. Either the team finds a suitable story for such tasks, or it spends its own swimlane on the board for work “under the bonnet” and reduces the velocity e.g. by a kind of technical flatrate. Consult your Scrum Master on this, but don’t let yourself be talked into technical stories – stay firm! Details can be found e.g. in [9] and [10].

5. Boost: A secret weapon – acceptance criteria in the form of concrete examples

At the “German Testing Days 2018” I gave a Pecha Kucha lecture with the dramatic title “Acceptance criteria – misjudged, maltreated, wasted”. Unfortunately, the opportunities that lie dormant in testable acceptance criteria are in fact often wasted, and instead “acceptance criteria” becomes a story – even if it may sound harsh – all sorts of things are stated: additional/further/new requirements, non-functional requirements, undecidable things like “the system must react quickly”, or simply nothing at all (“are obvious anyway”). Here you get to know a method that can turn this unloved mandatory field into a real “boost” in the agile team.

In an ideal world, acceptance criteria would be test cases from the outset, i.e. described in an executable way, clearly decisive and repeatable. If you and your team are already handling this: congratulations! The least that good acceptance criteria should always be are concrete examples. This clever approach has its own name: “Specification By Example” ([11]). You can find such examples for a story with the following little thought experiment: Suppose your team signals that it has finished a story and you can proceed to acceptance – and continue to suppose that you only have 10 minutes for this acceptance! What would you want to see or do in these 10 minutes in order to be able to decide on acceptance after the time runs out? This is exactly what you write down as acceptance criteria, and the results are – examples! Give it a try.

In my experience, this is a very good idea, because an acceptance test cannot and should not replace a systematic, methodical, risk-based test. Acceptance is a matter of trust, and you have to ask yourself what you want to see in order to trust the team and its work results. These can be indispensable standard procedures that have to work always and everywhere, or particularly tricky exotic constellations, or test results of the team, or a mixture of all of these: The decision on this is solely up to the PO!

If you now write down these examples (based on “Behavior Driven Development”) very close to the test case – for example with the three-part division “Given/When/Then”, with concrete input and output data, but without UI details if possible (see Boost 3) – you and your team will gain several advantages:

• Stories equipped with such examples are understood by the team faster and better. Logical: If you want to learn and understand something new, you are also grateful for examples!
• These examples are a worthwhile starting point for test design activities in the team.
• They are hot candidates for automated regression tests, as they express what is “most important” to the client (in this case you as the product owner).
• The team no longer needs to ask itself what it will demonstrate in a demo to create a finished story – because that’s exactly what the examples already describe.
• And these examples can be reused in online help, training material and other documentation.

Not bad, is it? That’s why I call “examples as acceptance criteria” a secret weapon. You can find more details e.g. in [12].

Outlook

This was the first part of the two-part series “Boost your Backlog”. Part 2 deals with testable specifications, valuable documentation, story editing, optimal refinement and DEEP. This acronym stands for … oh, I’ll just tell you about it in part 2 of my contribution. I would be happy if you would then drop by again.

Notes:

If you like the article, please feel free to share it in your network. And if you see aspects differently or want to add to them, please get in contact with Dr. Christian Brandes.

[1] Brandes, Christian: Verständnis durch story-spezifische Artefakte: Requirements Engineering in agilen Projekten
[2] Podcast: Agiles Requirements Engineering – wie geht das?
[3] Blog: User Stories are not requirements
[4] Frank Zappa: Jazz isn’t dead. It just smells funny.
[5] Jeff Patton: “User Story Mapping”, O’Reilly 2015
[6] Schubert, Monika: Von der Impact Map zu User Storys
[7] Podcast: Sind Job Stories eine echte Alternative zu User Stories?
[8] Blog: Feature Teams vs Component Teams
[9] Blog: Why technical user stories are bad
[10] Podcast: Wie passen nicht-funktionale Requirements und technische Stories in ein agiles Backlog?
[11] Gojko Adzic: “Specification By Example”, Manning Publications 2011
[12] Podcast: Akzeptanzkriterien als konkrete Beispiele – wie geht das genau?

From QualityMinds you can find more articles in the t2informatik Blog:

What does t2informatik actually do? One click and you'll know.