Boost your backlog – Part 2

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

6. Boost: Provide a testable specification per story to help the team!

The main message of Boost 1 was that a story is different from a requirement and does not contain all the details the team needs to get the job done in the sprint. But how does the team get those details?

Ron Jeffries already pointed out in 2001(!) with his CCC principle [13] that stories have a social aspect: They should encourage “communication” – his third “C” besides “Card” (= a story is a planning artefact) and “Confirmation” (= a story needs testable acceptance criteria). In the spirit of the Agile Manifesto, the team should therefore, during the sprint, engage with the product owner, the customers, other teams, with itself – with whoever it needs to! – and get the necessary detailed information directly, instead of pushing tickets or going through extensive documents. There’s nothing to be said against it – but in some situations another way even helps the team more.

Suppose a story requires that a result should be different depending on the user roles and rights. Why this story – this work package and “container”! – not provide a decision table that specifies in a compact, understandable and easily testable way which role-rights combinations should lead to which result?

So this is exactly where the toolbox of “classic” RE can prove useful for agile teams: If it turns out that a piece of documented specification (e.g. a UI sketch, a process diagram, a decision table, a class model, …) helps the team to understand the job faster and better and thus do a better job in the sprint – why not add this artefact to the story? This is pure agility: try it out, learn, improve – whatever helps the team is allowed.

Figure 3: Reaction of a Scrum Master after application of Boost 6

One question that is inevitably asked at this point, by the way, is: And who creates these artefacts? Does this mean that every product owner must be a trained requirements engineer or business analyst? The answer is “no” (although it would be no harm, of course): The artefacts are created by whoever can – the PO itself, or someone on the team, e.g. a former RE expert, or both together in the pairing process.

If interested: For this purpose we have developed a lightweight tool, the so-called “Helpful Artefact Map” (HAM), on which PO and team gather those document types (“artefacts”) that have helped in different story situations. As a cherry on the cake, this poster not only gathers collected team experience, but also suggests suitable test design methods for each artifact, which can improve testability and test effort estimation. Details can be found in [1].

Figure 4: Structure of a “Helpful Artefact Map”

7. Boost: Only document what has value! And yes, these can even be models!

The second pair of values in the Agile Manifesto does not say that “nothing more should be documented” – unfortunately another misunderstanding to be found. It rather says that no documentation is created just for the sake of documentation, because the result too often ends up as dust-covered “cupboard goods”. Agile documentation means only documenting what is of value and use to anyone!

But how is this value created? Two possibilities:

• Either a document must be created for a story (because required by contract, process or regulation) – in which case it should be recorded in the “Definition of Done” anyway.
• Or the document helps the team – i.e. the team has decided that the documentation effort is offset by a recognisable benefit for the development and testing of the backlog item in question.

We have already seen two examples of this type of benefit: the use case modelling and subsequent process specification in Boost 2 and the “Helpful(!) Artefact Map” in Boost 6. Time for a confession: You have already been accused of several classic RE/modeling techniques in this blog post, although we are talking about agile teams here. Didn’t hurt, did it? Modelling has had a particularly hard time since the advent of agile frameworks, because models have been completely thrown overboard by many agile teams, perceived exclusively as “ballast”, because UML, BPMN & Co. are “just documentation” (which is not true) and many modelling tools admittedly don’t exactly impress with their ease of use.

But in fact, models – in the right place and in the right amount – can be useful for every product owner and every agile team. Think for example of customer journeys! A detailed practical example of this thesis can be found in [14], so here are just two final tips:

• “Well-dosed” modelling also means not necessarily using all model elements of a notation. Remember the use case example from Boost 2: The benefit was achieved without using “extend” or “include” relationships or other advanced constructs. Incomprehensible models have no benefit (see [15] for blatantly failed examples of this), so please always think of the goal and target audience when modelling.
• And what really rocks in agile teams: modelling with Post-Its. Describing a process together in a team without having to cross out process steps or drag arrows all over the flipchart – just hang Post-Its as nodes on the whiteboard and rearrange them if necessary – and at the end of the process, file a photo protocol and it’s good! It’s also fun.

8. Boost: The tailoring of large stories

You could easily write a whole book about appreciating user stories – whether by means of story points, T-shirt sizes, “animals that scare you” (no joke!) or “ideal days” – even today. No wonder: Teams that, before their agile transition, had to regularly deliver hourly estimates of work packages to a project manager on an hourly basis, find it difficult to break away from this hourly thinking or to work with “relative” sizes based on a reference story. But these are all topics where your Scrum Master can help the team. So for everything that follows, let’s assume that your team is practicing a working estimation methodology and that they have information about their “team velocity”, because: Both are necessary to be able to make a statement like “This story does not fit into the next sprint! When this sentence is heard, you need to get to your backlog and “tailor” stories.

The good news is that there is a bag full of useful heuristics for “story splitting” that you can use and build your own pool of tools over time. Starting with splitting using signal words like “and/or”, you can split stories along process steps (see Boost 7 – yes, a model can help here too!), or by roles, by normal and alternative processes (… models! …), by acceptance criteria and much more. You can find a collection e.g. in [16]. It is important to note that these are all professional criteria for editing, which are largely still in the problem area and which you should therefore be familiar with.

In principle, a story cut according to technical or organisational criteria is also possible – e.g. according to architectural considerations, team knowledge, availability of placeholders in test environments, and even according to the team’s absence planning. The recommendation: Weigh these up together with the team, but prefer to cut according to technical criteria. After all, we are talking about user (!) stories that are supposed to have a business (!) value. More about this in Boost 9.

PS: Product owners keep asking me how they should “best value their stories”. My answer: not at all! Estimating work packages is the job of the team! (Prioritising, however, is one of your own responsibilities as a PO! By the way, if you find this difficult, have a look at “Impact Mapping”). That’s why it’s so important to get an initial rough estimate from the team early on when refining new stories. You will also learn more about this in the next Boost.

9. Boost: How to get the most out of a refinement

With the tools gathered so far, it is easy to deduce how you as a PO can design the backlog refinement in such a way that maximum benefit is created from the team’s point of view. What goals should you pursue with the Refinement?

• Early understanding and planning transparency: The team develops an accurate picture of which customer requirements are likely to be implemented in the upcoming sprint. It can therefore develop and discuss initial thoughts about possible solutions “on a low flame” and, if necessary, incorporate this “outlook” into upcoming decisions.
• Early feedback on planned stories: As a PO, you learn which specification of which of the resulting stories is considered helpful by the team and is therefore desired (see Boost 6), and ideally you can prepare them for the planning stage. In addition, you will receive first signals from the team for estimating the stories and for tailoring them, or more precisely: the team’s rough estimate will help you to avoid putting too many stories into the next planning package. And for stories that are already estimated as “too big for a sprint”, you will receive additional (technical) ideas from the team on how to split such stories in addition to this important hint (see Boost 8). Last but not least: You can also get initial feedback on your prepared acceptance criteria regarding their comprehensibility and feasibility – especially from the test experts in the team (see Boost 5).

As a consequence, you will achieve that the efficiency and effectiveness of the Sprint Planning is such that the team likes to do this Scrum ceremony, routine and rhythm are created and the planning does not get lost in excessive discussions.

The goals are clear, here a word about the organisation. Some teams allow the refinement in every sprint a fixed time slot with the whole team, i.e. a regular date – this supports the above mentioned goals, but is comparatively expensive. Some Product Owners, on the other hand, let the refinement activities run in the background as a “background noise” and get individual team members per story as sparring partners for a refinement session in the “pairing”. Both work, and you should experiment together with your team to find out which form of organisation will help you most. Your Scrum Master will certainly be happy to support you in this.

10. Boost: Keep your backlog DEEP

“DEEP” is an acronym here and stands for

• Detailed appropriately: Stories that are to be implemented in the near future are described and worked out in more detail than those that are only implemented later, at some point or perhaps not at all. They are also typically “smaller” than other stories (see Boost 8).
• Emergent: Your Product Backlog is alive and constantly changing. So if you as a PO work on it every day, you should not worry – on the contrary!
• Estimated: Stories that will be worked on only in the future are not yet discussed and sufficiently understood by the team, so the associated estimates are inevitably rough. Conversely, the estimates of upcoming stories should be more robust.
• Prioritised: he stories with the highest business value should be given the highest priority and thus be the next to be considered by the team.

This gives you a helpful metaphor of how your product backlog should look “as a whole”: imagine your backlog like a funnel (or, if you prefer the other way around, like an iceberg). New wishes and ideas are tipped into the funnel at the top and are usually still rough, concise, unclear, uncoordinated and thus far from those that finally fall out of the funnel at the bottom and are judged “ready for the next sprint” by the team. Your job as a PO is to sift through all these items and develop them further according to business value – in other words, to decide whether they are stories at all (see [10]!), and if so, to coordinate them with customers/stakeholders, prioritise them, describe them, cut them, provide them with acceptance criteria and “refine” them until you can finally bring them into product planning. One of your central tasks is to shape this process of selecting and “wandering” through the backlog of backlog items. You have received tools for this in the previous boots, and details of DEEP can be found in [17].

As an outsider, you can often tell how well you have the backlog under control by how “tidy” your product backlog looks, i.e. how many and which backlog items are in it and what the items that are planned for one of the next sprints will look like. So it is best to take a step back from time to time and ask yourself: Does the quality of my backlog satisfy me? And if not, what could I do better?

Finally, two short practical tips:

1. It is ideal to have a “stock of finished stories” for the next 1-2 sprints in your backlog as a PO. Because sometimes the team miscalculates, or show stoppers appear in the planning, which nobody thought of in the refinement – then it is useful to have a reserve of alternative work packages for the team in the backlog.
2. And – if you have influence on this, because some tools and their configuration are set company-wide – keep the number of item levels in your backlog as low as possible! To be honest: With “Epics” and “Stories” (tasks are created in the sprint backlog and belong to the team), supplemented by “Themes” for tagging according to theme coherence, I’m already getting very far in most product backlogs. Think carefully whether you really need additional elements like features, requirements etc. – because not only does your backlog get more complicated with each level, but you also catch idle discussions like “Is this another epic or already a feature? Prefer simple solutions, in the agile sense.

Conclusion

You will probably not find all 10 practical tips equally helpful when looking back at this article, but experience shows that this assessment differs from one PO to another. Hopefully, there were some new tips for you, which you can try out with your team in the next sprints and evaluate in one of the following retrospectives.

And if you see yourself as a “newbie” in the role of a product owner and have just been overwhelmed by all these tips and concepts, here is one last tip: As a “Starter Kit” for new product owners, I would like to recommend the triad of

• Use Cases & Story Maps – to find valuable stories for your (initial) backlog,
• Specification By Example – for testable and demonstrable acceptance criteria for each story,
• Specifications & HAM – as a collection of helpful artifacts that you can use to enrich stories for your team as needed.

Add to this continuous “pairing” with the team members from the beginning and you should get a successful start as a PO. Good luck on your journey!

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 contact Dr. Christian Brandes directly.

[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?
[13] Ron Jeffries: Essential XP: Card, Conversation, Confirmation
[14] Brandes, Christian: Modellieren im agilen Requirements Engineering – wohldosiert und leichtgewichtig
[15] Henschel, Gerhard: „Die wirrsten Diagramme der Welt“, Hoffmann und Campe 2003
[16] Blog: Splitting User Stories
[17] Pichler, Roman: Make the Product Backlog Deep

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

t2informatik develops and modernises software as a service provider. Click here to learn more.