Questions about backlog refinement for internal products

Earlier this week I spoke at ProjectSummit*BusinessAnalystWorld in Chicago, a conference for business analysts and project managers. Given the audience, I figured Backlog Refinement: “Writing user stories” is not the whole story would be an appropriate presentation.

As happened last week, there were some great questions that I thought I’d share along with what I think my answer was.

Or at least how I’d answer it if I were asked right now while sitting at my keyboard.

My team owns multiple products used by multiple business units. How should I organize my roadmap and backlog?

Teams working on internal products often have the opportunity to work on multiple products at the same time. Internal products often spend a lot of time in the maturity stage of the product lifecycle so they don’t always need a lot of attention week to week. It’s natural therefore to form a team around supporting multiple products. This works great until more than one product needs attention at the same time.

It becomes even more exciting when you have multiple business units that all use the same products. In reality this is no different than a B2B product with multiple influential customers.

Except if you’re just starting to move to a product approach to handling your internal systems you’ve got some retraining to do with your stakeholders to properly set their expectations. On the positive side, they may not have to wait around for a bunch of problems to pile up before a project gets funded to address them. On the other hand, every request they send in is no longer a requirement.

Ultimately you want a single view of all the items that you’re considering when you make your prioritization (deciding what you are/are not going to do) and sequencing decisions (put the things you’re doing in order).

If your team’s portfolio covers multiple products that don’t interact or overlap, you may go with a separate roadmap and backlog for each product. That way all your stakeholders for a given product can see the items that you’re planning for a product you’re considering. The only downside to this approach is that your team may have to keep their eyes on multiple roadmaps which could get messy.

That may be a sign you need to change up which products you’re responsible for. You may still support multiple products, but they are all in support of the same business process.

In that case, If you support multiple products that overlap or all have the same stakeholders, you may be better off creating a single roadmap for those products, but differentiate them in some way, perhaps with different colored items or swim lanes.

The swim lanes are definitely helpful for splitting things up on your backlog.

How do you make the call between Later & Never with only a sentence?

This question is in response to my suggestions to prioritize in your roadmap and to not go into detail until you absolutely have to.

The underlying premise is the items on your roadmap are often very brief statements, and how can that be enough to make a decision whether or not to keep considering something.

It’s a reasonable point, but I could also argue that teams are expected to “estimate” how long something will take with not much more information.

My instinct these days is to practice ruthless prioritization so I’d suggest using the Hell yeah! or No approach from Derek Sivers.

If you feel anything less than “hell yeah!” about something, say no.

Admittedly, that does represent a mindset shift, but I think it’s a healthy way to start addressing the overlord that teams face.

If you’re not willing to do that, go ahead and keep it in the later column. Just realize the idea will mostly likely stay there and get moldy.

But doing that is better than going to the work of diving into more detail only to find you’re still “meh” at best about the idea.

What’s a good way to get rid of a bunch of backlog items?

Select all. Delete. If it something was important. It’ll come back.

That’s the flippant answer I use to get people’s attention. When some people hear that you can see the relief on their face.

When other people see it, you can see the panic.

So certainly read the room before deleting everything. A helpful first step is to start a separate repository for feedback and put all those items there.

Then create a ritual where every month, or every quarter you review that feedback and identify items that you should bring back into consideration. You’re looking for trends as opposed to isolated requests that seemed like a good idea at the time.

That also means when you get new requests instead of immediately putting them in the backlog they go in the feedback bucket.

Yes, a place where buckets can be helpful.

It keeps your backlog clean, and it helps you to start training your stakeholders that requests are feedback, not an immediate promise from you that you’ll deliver something. Because we all know that the likelihood of you being able to even come close to delivering on every request is slim to none.