From glorified backlog to customer success

The backlog as the sweet poison of anti-agility

“André, what is the most important competence of an Agile Coach?”

After a moment’s thought, I say, “It’s obvious, good software skills, ideally in Confluence or Jira”.

What reads ludicrously is the impression I get when reading some job applications for Agile Coaches. I call it “the sweet poison of anti-agility”. And this is the poison that many organisations and teams suffer from. It makes them sluggish, uninspired and slow. So slow, in fact, that great projects almost grind to a halt. And all the problems are caused by a pile of logs: the backlog!

How it all began: the log in the middle ages

How did the backlog actually begin?

In its original meaning, the backlog was nothing more than the logs stacked in the background of an open wood fire. When the fire threatened to burn down, it was replenished via the backlog. So the backlog was systematically burnt.

Let’s see what the Scrum Guide says about it: “In the simplest definition the Scrum Product Backlog is simply a list of all things that needs to be done within the project“. So the backlog is nothing more than a complete list of all known to-dos that are required to complete a project. It is a glorified to-do list. The tool manufacturer Atlassian puts it even more clearly:

The product backlog: your ultimate to-do list!

“But André, what’s wrong with an ultimate to-do list now?”

Apart from the words “ultimate” and “to-do list”, nothing.

The backlog suffers from severe obesity

Actually, a to-do list is a wonderful thing. I myself am a great friend of to-do lists and their delightful sister, the checklist. Useful tools that help my clients and me become productive. But every to-do list I know of that is not disposed of at the end of the day, what the great sociologist Niklas Luhmann also calls the “gift of forgetting”, grows. And it grows and grows. And one day, the needle of the backlog’s body mass index (BMI) moves irrevocably from the red to the dark red zone. The backlog suffers from severe obesity and the project literally has a heart attack. Hardly anything moves forward any more.

We groom, groom, groom with a broom

“But André, there is grooming! Isn’t grooming good?”

Grooming or refinement has the task of “keeping the backlog up to date”. Up-to-date means that the irrelevant should be disposed of. But what is irrelevant? The whole process of refinement reminds me of a Messi who is supposed to throw something away. He decides on … nothing! And I can well understand that, because everything was once important at a certain point for some unknown reason.

Appearance of the manufacturers: “Use our tools and everything will be fine!”

The backlog is heavy, the backlog is big, a good tool we should pick. And there are really good tools. The market leader has redesigned its old ticket system for incident handling in IT service management to look like the most beautiful Kanban board ever. It’s a beautiful façade that nevertheless doesn’t disguise what’s behind it. It remains a ticket system. And ticket systems have one characteristic that is indispensable for them: they don’t forget anything. That’s good for incident handling and very bad for creativity.

Unfortunately, it is also true: tools make a fat backlog just as agile as an escalator replaces your sporty stair climb. But back to our log.

The log calls: Muda, Mura and Muri

Why is “forgetting a great gift”? And why wasn’t the backlog as high as the Tower of Pisa in the middle ages and not sorted and inventoried daily?

Quite simply because the backlog is a colossal waste. And not only that, as a big to-do list it also creates an immense cognitive load. It blocks thinking with all its entries, so that new, simple and creative solutions have a hard time. The Product Owner becomes the facility manager of his ticket system.

In Lean Management, the process around the backlog is called “Muda”, “Mura” and “Muri”. These “M & Ms” are not sweet chocolate candies, but the three apocalyptic horsemen of “waste”:

• Muda – All the work around the backlog has no customer value. None at all! I don’t know any customer who buys a backlog, i.e. a statement of intent.
• Mura – Refinement and prioritisation is a spiral of work that is not triggered by the customer. It is a result of an agile process machine and causes stress in the team and negatively affects the morale of the troops.
• Muri – The backlog is great for measuring pseudo-productivity. We simply measure the burn-down rate. Oh, how productive we are, and if we work even harder, we are even more productive. Unfortunately, this leads to overheating and overtiredness, which makes some developers despair of Scrum & Co.

The backlog is nothing but waste and waterfall in agile guise. While in the waterfall era all activities of a project were pre-planned, now all activities of a project are continuously re-planned. Both are largely pointless in a complex world, because product success lies elsewhere, in customer success. And this customer success is not a component of agile methods.

My criticism of the backlog in summary

Now my criticism in summary, without any wood. The backlog is waste in the sense of lean management. It causes high storage costs, also called opportunity costs, because it causes a continuous administration process.

This management process is not triggered by customer requirements, but solely by the method or the framework used – e.g. Scrum. The team gets lost in details, while grooming as a continuous inventory exacerbates the problem of administrative overhead.

Ticket systems, on the other hand, are the wrong tools because the disposal of useless items in the backlog is costly and hardly enforceable. Deleting tickets is expensive!

Some time ago, the Standish Group did a survey of 2,000 software products to see how many of the delivered features were really used. The result was shocking: on average, a whopping 64% of all features were not used at all or hardly used at all, despite all the agile work.¹ This shows that the belief that prioritising over business value helps turns out to be empirically proven to be a misconception.

What we need is a new working basis. And that is called “customer success”! What makes the customer successful also makes your product and team successful. Unfortunately, customer success is not part of the Agile Manifesto. And that’s even understandable, because the gentlemen who put the manifesto together 20 years ago had other problems: Their projects were on fire.

“And André, how do you plan for customer success?”

From right to left to customer success

Customer success requires what Mike Burrows calls thinking from “right to left.”² Instead of planning from backlog, to features, to releases, the direction of thinking is rotated. Think about,

• what makes your customers successful in the long run! Keyword: Jobs to be Done.
• by which behaviour of your customers you recognise that the customer is successful in the long run! Keyword: Northstar Metric.
• by which user behaviour you recognise in advance how acute problems are solved and opportunities are seized! Keyword: Outcome-Based Planning.
• which features and experiments could be used to promote these outcomes! Keyword: Mini Backlog.

You can see from these examples that it is generally possible to consistently focus on customers and their success. Velocity, burn-down rate or the last grooming are not really interesting. Instead, it’s about making an immediate and lasting impact and making customers successful.

With Outcome-Based Planning to the mini backlog

My suggestion: Use your backlog as a list of ideas and turn to Outcome-Based Planning.

In Outcome-Based Planning, only the most important outcomes are planned. But what is an outcome? I like to use Joshua Seiden’s definition:

An outcome is a change in the behaviour of customers, users, people that contributes to the long-term success of the product (North Star).

Outcome-Based Planning means that instead of the full backlog, the next outcomes that lead to customer success are planned.

Example:

We notice that the abandonment rate of the customer journey for the initial registration to our digital platform is far too high. Customers are throwing in the towel far too early.

Instead of planning User Storys or features, it is enough to plan the desired customer behaviour:

We reduce the initial sign-up abandonment rate from 30% to 15%.

Outcome-Based Planning creates a roadmap of key outcomes. The roadmap consists not of features, not of epics, not of milestones, but of desired user behaviours. A backlog still exists, but only for the ideas to achieve the next outcomes in the next Supersprint, for example 2-4 months. After that, a new empty backlog is opened.

Conclusion

“Good André, I understand. The backlog, when it gets too big, can become a burden. It is unfinished work in the system, which is called waste in lean management. The constant preoccupation with the backlog costs a lot of time, while we remain totally in the dark about what really constitutes product success!”

The backlog was a good idea when projects were small and dinky. Today we don’t talk about projects, we talk about products and digital platforms. It’s not the market players who produce new features the fastest who win, it’s who makes their customers successful. To do this, it is more important to deal with the customer’s jobs and to concentrate on the outcomes in planning. User Storys and to-dos remain important, but in a narrow and manageable mini backlog. Just as small and useful as the woodpile next to the open fire was in the Middle Ages.

Notes:

[1] David Rice: Why 45 % of all software features in production are NEVER used.
[2] Mike Burrows: Right – Left. Der Leitfaden zu Lean and Agile für Digital Leader.
[3] Josuha Seiden: Outcomes Over Output. Why customer behavior is the key metric for business success.

This is a best of blog post 2023.

If you like the article or want to discuss it, feel free to share it with your network.

André Claassen has published further articles in the t2informatik blog, including

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