I do use backlogs. I don’t write user stories.

Some thoughts on backlogs, backlog refinement, and user stories and an explanation into why I use some of those things and not others. Your mileage may vary.

This week has been a bit hectic, so I thought I’d share a couple of potentially contrarian, and hopefully helpful, takes I posted on LinkedIn this week

Both of these topics speak to common points of interaction amongst product teams. They are also practices that teams do in a certain way because they think that’s what they’re supposed to do.

Yet they don’t know why.

My intent with these posts was to bring some sanity back to practices that are generally helpful if you focus on why you do them rather than the techniques you learned in your CSPO class.

In defense of backlogs and backlog refinement

Bashing backlogs and backlog refinement has become a favorite pastime of thought leaders. That’s fine, no one forced them to use a backlog. I however have found that a properly refined backlog can be helpful for internal products. Let me explain.

I’ve worked on internal products for the vast majority of my career, and I usually find myself working on a combination of larger changes and minor tweaks to a product.

I’ve found that having a backlog helps the team keep track of the things we decided to focus on over the next couple of weeks to a month.

Those backlog items also become a handy place to note specifics about the changes we’re making so that people remember what we’d talked about.

I’ve also found the more consistently sized your backlog items are, the smoother they flow through your team’s workflow.

So, we (the product team) split the larger changes into smaller changes that are roughly the same size as the minor tweaks.

Not only are smaller changes easier to implement, they are also faster to test and debug because the change is fairly isolated. If something doesn’t work they way you expected, you have fewer places to look when dealing with a small change.

We don’t have a backlog and do backlog refinement because “agile said to”. (Agile doesn’t “say” anything.)

We don’t do them because otherwise we wouldn’t be “doing scrum” (I could care less).

We have a backlog and refine it regularly because we find it helpful and it helps us be more effective.

After I posted those thoughts in Substack notes, I received this comment from Vasco Duarte:

Hey Kent! Appreciate the articulated defense of the backlog and the refinement process.

But I'm curious, when would you day a backlog is “too large” or a backlog item “too old”, and when would a backlog of such items become more of an impediment than a helpful tool (and I agree it can be helpful - with certain constraints)?

What's your take on that?

Here’s my response.

If you dread having to go through the backlog, it’s too big.

If you can’t remember why a backlog item got created, it’s too old.

More practically, I’ve adopted my practices over time to reduce the chance that the backlog gets unmanageably big or backlog items go stale.

The main way I do that is to have a Now - Next - Later - Never Roadmap with the big items (hopefully problems to solve) track on it. When some thing lands in Now, that’s when I break it down and create backlog items.

Of course there are going to be those minor tweaks that come up. If it’s something that I know we’re going to want to tackle within the next 2 - 4 weeks, I’ll put it on the backlog. Otherwise, I have a separate feedback list where I put requests and feedback on so they don’t clutter up the things the team is actively working on.

I just counted my current team’s backlog and it has 23 items on it and that’s for three separate brand focused websites.

In times before when the backlog felt to big or backlog items felt too old, I removed the old items. Preferably deleted all together, but if others on the team started having heart palpitations, I put them in a removed status that doesn’t show up on the board view of the backlog.

Backlogs yes. User stories? Not so much

If you want to build shared understanding with your product team, you may not want to write user stories, job stories, or any of the other fill in the blank templates out there.

In his book User Story Mapping, Jeff Patton explained the intent behind the name user stories:

Stories get their name from how they’re supposed to be used, not from what you’re trying to write down.

He went on to explain Kent Beck’s idea behind stories:

If we get together and talk about the problem we’re solving with software, who’ll use it, and why, then together we can arrive at a solution, and build shared understanding along the way.

User stories were intended to sit in the problem space as a way to describe the problem.

Somewhere along the way product people were introduced to user stories in this fashion:

• Write them in the form As A [who], I want to [problem to solve], so that [why]

• Use the three C’s

• Make sure to use INVEST too

So people would turn themselves into knots trying to reword fairly straightforward backlog items into some tortured form of Vogon poetry trying to meet the template.

Don’t blame the template. It has the key pieces of information there, but folks gradually lost sight of why they were using it.

More than a few folks felt something was off, but couldn’t put their finger on what it was. Then they heard about Jobs to Be Done, and thought it was a great idea.

We should focus more on the job our users are trying to get done, rather than the users themselves, and we should add more in about the context.

That’s a great idea.

And then they proceeded to create a different Madlibs template.

“When [Situation] I want to [Motivation] so I can [Expected Outcome]”

Folks who had up until recently been teaching the original user story framework started falling all over themselves to teach the new framework.

And forgot to really explain why, or at least the people they taught didn’t remember the reason why.

Yet in both cases the reason why is the important bit.

So I don’t write user stories, or job stories.

When I record backlog items for my product team (we rely on the written word because we’re distributed across two continents and multiple time zones), I make damn sure I note:

• who the change is for (if that’s relevant)

• what they’re trying to accomplish

• in what situations it applies, and

• why we want to help them accomplish that.

And then we discuss it.

Because the product team wants that context. They usually don’t care what format it’s written in as long as it’s clear.

So the next time you hear about some new template for conveying information amongst a product team, don’t get hung up on structure, make sure you include the information your product team needs.

Donna Fitzgerald left this reply in LinkedIn

Thank you for this timely explanation. I was just reflecting on my own struggles with user stories. I had a dev team lead who wanted to write up stories that had nothing to do with our customer or the product that we were building (accounting software.) just so he could get something in the system. I quit the project a week later.

Here’s my response.

You're welcome. Your situation with the dev team lead is quite common.

When product team members suggest items that on the surface don't appear to have anything to do with users or products, I make it a point to ask what user or business impact the change would have.

Of course usually the requests I run into are things like updating API code to .Net8. My current team has gotten good at explaining we need to do something, and immediately saying why. More often than not, those types of suggestions surround preventing vulnerabilities in the code or preventing compile or deployment issues.

I also suggest that team members who identify those changes write up the backlog item. Primarily because they have a better idea than I do regarding what info they need to complete the backlog item.

I should note we don't do backlog items for the sake of having backlog items. We have traceability between backlog items and code commits. It makes deploying the right things easier.

One other thing - just because something gets on the backlog doesn't mean it's going to get done. And for those items that don't look you're going to do them, it's best to delete them from the backlog as soon as you determine that.

That’s my story, and I’m sticking to it

I intended those posts to get folks to reflect on how they currently describe the solution with their product teams. Next week, I’ll share some tips for effective backlog refinement.

Do you have thoughts about backlogs and user stories? Questions? Tips you’d like to share? Let me know.

Thanks for reading

Thanks again for reading InsideProduct.

If you have any comments or questions about the newsletter, or there’s anything you’d like me to cover, let me know.

Talk to you next time,

Kent