Forem: Paderich

From Chaos to Clarity: Fundamentals and Best Practices for an Effective Backlog

Paderich — Tue, 27 Jun 2023 13:00:40 +0000

Introduction

Over the past few years, I've had the opportunity to inspect numerous backlogs. Based on these experiences I was able to create a short list of rules on how to handle the backlog in a more effective way. My personal goal was to replace a bit of the everyday chaos with more clarity and aiding Product Owners in maximizing the value of their products.

Fundamentals

What is a Backlog? Based on the Scrum Guide, a Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.¹

In short, a backlog is an ordered list of todos, prioritized to ensure the most valuable items are tackled first, thereby creating a clear pathway towards the product goal and value realization.

That said, by definition, a backlog is a prioritized list that should be constantly revisited and revised by the Product Owner. This continuous refinement ensures the development of a product that aligns with the envisioned goals. Moreover, the backlog serves as a value-maximizing stream, always mirroring stakeholder needs in relation to the anticipated return on investment.

Backlog Safari

Now, for the amusing part. I'd like to share with you some of the most interesting backlog approaches that I've encountered in the wild world of Agile.

The Backlog backlog

I once had a gig where the Product Owner established shadow backlogs to organize his stories, and therefore, his own thinking process. He didn't just have one backlog; he had four of them, each with a prioritization marker on it. For instance, "Backlog 1 - High", "Backlog 2 - Low", and the most interesting one, "Backlog 3 - Not Relevant". In the end, the Product Owner had multiple backlogs to manage but was still unable to make the right decisions.

Support prioritization of Backlogs

What are you going to do if you are unable to prioritize your backlog? Right, you implement things such as tags and custom fields! Back in the day, there were two Scrum Teams, both working with one product backlog. To manage the team separation, they created placeholder user stories like "Team A Backlog Start" and "Team A Backlog End". All of Team A's topics were placed between these dividers. That was the first attempt to manage the backlog. After that, they established a new custom field called "Priority" and created a classification from "4 - very low" up to "1 - very high". But they didn't stop there, they also implemented tags for each team and a tag to indicate if it was a backend or frontend topic.

At this point, there's not much more to say. It was simply the most ineffective approach I've ever encountered.

The Pit

On the other hand, the 'pit' is a fairly common mistake. The Product Owner attempts to keep everything and throws it into this large pit known as the backlog. Each planning session turns into a disaster, with the Product Owner constantly trying to remember what the next thing to tackle is.

The Estimation Monster

The 'estimation monster' often arrives hand in hand with the pitfall of over-planning. It's not just that you have 100+ tasks in your backlog; each task carries an estimate as well. Some of these estimates are months old, leading to the development team's frustration as each sprint fails to reach completion.

The wholly plan

The 'whole plan' is a common mistake too. The idea is to plan the entire application upfront, fill the backlog with hundreds of items, and then lean back and let the other people do their job. Hmm, this reminds me of the good old waterfall days, where each and every project was successful thriving this approach.

Best Practice

So, what have I learned from my foray into the agile wilderness? My experiences can be distilled into a few, but highly effective rules:

Aim to populate your backlog with items that cover a time span of, at most, three sprints.
Prioritize your backlog on a regular basis and make use of techniques like backlog grooming.
Only estimate the tasks you intend to tackle in the upcoming sprint.
Always keep tabs on the needs of customers and stakeholders, and consider the Return on Investment (ROI).

Conclusion

To sum up this blog post, I want to emphasize: Please take care of your backlog. There should be one backlog for one product, nothing more. The established methods to prioritize and order your backlog items are effective, and very often, you don't need anything else. If you recognize any of the backlog pitfalls mentioned in this post within your team, don't hesitate to call them out and assist your Product Owner in maintaining an excellent experience.

Source:
¹ https://scrumguides.org/scrum-guide.html#product-backlog

Writing Effective User Stories: 5 Essential Rules

Paderich — Sun, 18 Jun 2023 13:24:03 +0000

Intro

As far as I know, there are at least a million ways to write User Stories, and that sucks. Some of them are good approaches and some are just crap, more like full-blown specifications from the old days. In the past 10 years, the way I write User Stories has evolved from the Stone Age to a more modern century. I guess it’s like real life, everything evolves and it will always be somewhat wrong in retrospect.

Anyways, I’d like to share some ideas on how I write User Stories today.

Boundaries

From my point of view, a User Story delivers value and to be specific, one User Story delivers one user value. I’ve read so many Stories where it goes like this: "As a PO I want to bla bla and bla bla bla and after that foo foo foo, so that x, y, z." Well, there are a lot of issues with this example. First of all, what kind of User is the PO in this Story? Maybe they are developing a Scrum Tool, which in this special case would make sense. Otherwise, it's just one lazy Product Owner. The second issue with this Story is the concatenation of user values. It seems to be one Story, but by using conjunctions, this tiny little Story swells to a bigger picture, maybe a Feature or even an Epic.

So, to be more specific, I try to follow these rules when writing User Stories:

One Story, one User Value
Try to follow the "As a [Role] I want to [Function], so that [Goal]"-Template
Always define User Roles, like "Administrator" or "Customer" and so on
Try to specify Personas based on your User Roles, to be even better in describing your User Value
Always make your User Story testable from a user's perspective.

Deep Dive

Let’s have look at my list of rules and what I mean by that.

One Story, one User Value

It’s super important to write a User Story which tries to generate just one User Value and not a list of values. Why is it important? Well, one value is much more easily testable in the end. Also, one value is, if necessary, easier to break down into development tasks. Another positive side effect is that one value can be delivered much faster.

Try to follow the User Story-Template

Back in the old days, when User Stories first came up, a story consisted of a simple card. On the front was written something like "A company can pay for a job posting with a credit card" and nothing else. At the back of this card, you could find some tests to make sure your User Story delivers exactly what you want. You may ask, what is wrong with this approach? In short: nothing. But, User Stories are much broader in use now, and many more people are making use of it, even if they have no experience with it. To prevent people from writing a novel instead of a User Story, the User Story template has been invented. It helps to nail your expected goal down to just one value. And if your goal does not fit into one value, well then you have to write more than one User Story.

User Roles

A User Role is someone who is using your application. For example, if you want to create an online book shop, you have at least 3 roles:

The Customer
The Seller
Page Administrator

Based on these roles, you can write better User Stories to deliver specific value to them.

Personas

In addition to Roles, you can develop Personas. Personas provide a more in-depth look into a User Role. For example, a Persona for "Customer" could be "Susan the Customer".

Susan the Customer

Demographics:
- Age: 23
- Interests: Volleyball, Finance, Dogs
- Digital native
Background: Susan is an Accountant and wants to teach herself to get better in her job.
Goal: An easy way to search and buy business books

You see, based on this Persona, you can create a User Story which provides much more value to your user base.

Testability

In order to create a User Value, you have to make sure that you deliver the right thing. To ensure this, you have to test your User Story. There are a lot of ways to test a User Story, and it doesn't start at the end of the implementation. An experienced development team will test their implementation with each commit to make sure nothing breaks. Also, an experienced team will always try to reflect the User Value and consult the Product Owner to ensure they are doing the right thing.
Another significant point when it comes to testability is to test the User Story from a user's perspective. A user will never test if property "Age" is persisted in your database. A user wants to add their age via an input field, refresh the page, and still see their age.
You see, there are several layers of testing within a User Story:

Unit Test
Integration Test
System Test
User Acceptance Test

A good development team is able to deliver all testing stages for each User Story in one iteration. But the overall goal for a User Story is to verify that the user value, which is described, is delivered correctly.

Summary

I hope my point of view was helpful and you can see why I think there are a lot of bad User Stories out there. My goal was to deliver a quick guide on how to write good User Stories, simply by sharing my list of rules.