How being lazy can be much more efficient

Some time ago, the Product Owner Team of one of our client projects was restructured. As a result, I became part of the Product Owner Team.

What? Product Owner Team? The Highlander rule applies to Product Owners: There can only be one!

Yes, there can be a team. In fact, it’s perfectly okay if there is a team. While the Scrum Guide says that there can only be one Product Owner, this does not mean the number 1.

Instead, the Scrum Guide makes it clear that there must be a single authority that makes a decision. This authority must not block itself. How the decision is made (dictatorially, democratically, by meritocracy etc.) is not defined. At least that is my interpretation of the number 1. But let’s get back on track.

Starting into new projects is always exciting. New system, new colleagues, new client, new environment. In this case, none of that applied to me. I already knew the system (because I programmed it myself). I knew my colleagues, too. I was familiar with the environment and the client. Much more interesting was the backlog.

The backlog was the only thing that was really new to me in this particular project. In fact, I had never seen one with so many items — from different perspectives, different project phases, in different formats and writing styles. So: What to do as one of the project’s new POs?

Items upon items upon items

This is one of the main reasons why we are needed as product owners. And if you don’t enjoy it, maybe you’re more suited to a different line of work. It’s simple: when confronted with a full backlog, our main task is, of course, prioritization. A PO has to work through the noise and figure out what is important and what isn’t. We are here to keep the train on the tracks, instead of getting sidelined.
In the current project, the first step was to rigorously divide this huge heap of items into two disjoint stacks:

• Stack 1 contained everything we could use within the next two to three months.
• Stack 2 was all the rest, which could be ignored for now with a clear conscience.

Work will now continue only on stack 1. There is still a lot in this — some would say, it’s still way too much still — but it’s something to work with.

Items from different project phases

Anyone who has had the pleasure of studying history will hopefully agree with me: Every event must be interpreted in its historical context. We cannot condemn Charlemagne for the Lombard campaign — even if, from today’s point of view, military intervention no longer seems appropriate. At that time, Charlemagne took a perfectly legitimate path.

Back to the backlog: A ticket that has been in the backlog for two years is obsolete. This is a fact that must be accepted. The information contained most likely does not correspond to the current situation. The requirements for the application have changed. The design is different. Probably new edge cases have been added or do not need to be considered anymore. Or the problem has simply been solved in another way.

Now the question arises: what do we do with backlog items that have grown beards as long as Methuselah’s?

Basically, there are only two possible strategies for me: Rewrite or delete. Rewriting is really time-consuming. You have to get back in touch with the stakeholders, talk to developers, reassess the changed situation. I don’t want to go into the rewriting of tickets any further, as this is a science in itself.

And what about deletion? Deletion is simple. Deletion is easy — once you start doing it.

Delete, delete, delete?

The fear of deletion is widespread among data hoarders. Being afraid of losing something essential is primeval, it bubbles up in us and gnaws at our ability to think rationally: what if that one sentence was important after all? What about the acceptance criterion? Is there perhaps still an edge case hidden there somewhere that we will all forget? Am I perhaps just deleting the single feature with which the product will revolutionize the market? Well, reality check: that’s the kind of thinking that does not lead to great outcomes.

The central idea to keep in mind is: if something was important, it would have been done already. If you’re hoarding market-disrupting features in your backlog, you should rethink your prioritization. Acceptance criteria from the early 2000s are not important today. And regarding edge cases: Don’t worry, they’ll show up on their own when the time comes.

By itself, the deletion strategy does not work too well, as the fear of something getting lost always persists. As a workaround, you can agree on a de-facto deletion status: We move the items to a special backlog, what I call limbo. In limbo, they can keep stewing. And having less noise in the product backlog makes me happy. As a PO, I am satisfied because I can see the project more clearly. And most importantly, everyone involved in the project is happy, because all information can still be accessed, if needed.

The less noise in the backlog, the easier it becomes to concentrate on things that are important. This applies to stakeholders, product owners and devs.

After so many deleted tickets, almost deleted tickets and rewritten tickets, I can enjoy peace of mind — at least for now. The backlog is readable again and can be processed by a human brain. Of course, this is the state I want to keep.

Stop wasting your time (and do work that has value)

I really spent a lot of time and effort to get a clean product backlog that we can work with effectively. So now, I am very satisfied and would like to maintain the status quo.

Of course, the status quo does not remain the status quo for long. New items can and will arise, no matter how clean the backlog is. Again, the important thing is setting the right priorities. Keeping the project’s big picture in mind, what is significant and what is less so?

Small items (e.g. removing blank spaces from an e-mail, moving a button a few pixels to the right etc.) can be processed quickly. But the overall value of solving small issues is in most cases minimal. Or to put it in a nutshell: even if I am only wasting a bit of my time, I am still wasting time!

Even if I am only wasting a bit of my time, I am still wasting time!

In item prioritization, it is critical to not get carried away enough to give high priority to things that don’t deserve it. Always tackle the important things head on and solve smaller issues down the line. In fact, even most stakeholders share this view, when presented with it correctly.

When the team is working on a mission critical goal, such as, for example, developing a new market, it is my job to put things in perspective. Usually, when dealing with seemingly less significant tasks, I like to put forth the question: does taking care of this blank space in an email move us forward in regard to our current critical goal? Sometimes, the answer is yes. Most often, it isn’t.

I cannot stress enough how important it is to define corporate goals that serve as guardrails through a project’s phases. The big, mission critical business goal saves us from drifting into the small, small world of solving less critical items. And in effect, we can invest our time into things that have high impact and value for the company.

At this point, I want to make clear: I cannot just strike down every item. Now and then I am actually forced to do some work. In this case, I just draw up an item draft and ask where to place it on the roadmap.

In closing

The team is working according to Scrum and taking care of items that currently have the greatest value for the stakeholders. This is exactly how I work as a product owner. The further back an item is, the lower its value. So: why should I invest valuable time into preparing items down to the last detail that might never be implemented? Why should I have developers create Plans of Attack if the issue will not, in fact, be attacked? Why should I generate more noise in the backlog and lose my overview? Nah, none of that makes sense. I’m going for coffee.

At least with coffee, you can’t really make it worse.