Skip to content
Phil's Library

jrothman.com - How Good is Your Backlog. How to Shape the Work for Product Success, Part 2

Innovation Steps for a Backlog

Most products need both interim steps and experiments to get from Point A to Point B

Maybe your team does have Ready criteria for their backlog. But they look at the backlog item, and they say, “Oh, this is way too big. We have no idea how to start.”

That “no idea” often means the work is too large, unclear, or not based on a specific customer with a specific need. Right now, the term I’m using for that is work that is not “problem based,” but “feature based.” (I clearly need better language!)

How does this occur? Often, because the product leader has not yet separated all the problems that they want the team to solve. They might not realize that or even know all the problems they want to solve. Instead, they see where they are for the product (Point A) and where they want to be (Point B). But there is no easy way to see the various paths from Point A to Point B.

Why is that? Because it’s “obvious” to everyone except the people doing the work. (That’s when a planning miracle happens here.)

Point A to Point B for a Backlog

What too many managers and inexperienced product leaders think: either a miracle or the path is straightforward.

Instead of thinking a problem is “obvious,” it’s worth taking time to clarify the problem(s) to shape the work.

Clarify the Problems to Shape the Work

Section titled “Clarify the Problems to Shape the Work”

I wish there were a way to create an “obvious” path from where the product is now (Point A) and how to get to the next useful deliverable (Point B). That’s why I prefer very small stories, each of which focuses on what a customer can do. That clarifies both the problem and shapes the work.

But sometimes, the product needs a lot of shaping before the team can deliver anything useful.

Instead of blindly proceeding, there are several ways to shape the work:

  • Basecamp’s ” Place Your Bets,” where senior people work for the team, not necessarily with the team.
  • A variation on that, where the next available person shapes the work.
  • Workshop or brainstorm all the various problems to solve in this feature set before anyone starts to write tests or code.
  • Plan to spike at least some of the work to start to separate the problems from each other. That includes tests and code.

I’ll start with the idea of senior people (or another team) doing the research before handing the work off to the team doing the work.

Senior People Start, the Team Finishes

Section titled “Senior People Start, the Team Finishes”

Interim Steps for a Backlog

When other people shape the work, they often think the work is obvious.

I don’t know if Basecamp still uses their Place Your Bets approach. But that page discusses how mostly senior people do all the initial R&D before handing the work off to the team. There are plenty of pros and cons to that approach.

Here are the pros:

  • Basecamp management decided how much they wanted to invest before (or as) they shaped the work. (They typically invest 6 team-weeks plus whatever the senior people do.) No asking for estimates.
  • That shaping de-risks most of the problems the team needs to solve. The senior people decide how much work the team can finish in 6 weeks.
  • The team only has to decide on their interim risks and deliverables. (Which is still risky and requires thinking, but not nearly as much as when the team has to do all the work themselves.)

After the team spends their six-week timebox, everyone knows that they can expect working product or some exposition of more risks at the end of that timebox.

However, there is a big problem with this approach that would not work for most of my clients: The senior people still have the problem definitions in their heads, not the team’s heads. And because the senior people did the thinking, and they “do not have time” to spend with the team, the senior people hand off the work to the team. But not all the rationale for the senior people’s decisions.

Because the senior people did most of the thinking already, the team does not know what the senior people thought. Most of the time, my clients ask senior people to work on something in this way, literally hand off the work to the team, and then the senior people are no longer available to discuss their thinking. (This is the chief programmer problem I described in One Secret to Free Yourself from the Overwhelm of Leadership Work.)

I am sure Basecamp’s solution works for them. But my clients need their teams to be able to work autonomously.

There is a similar solution, where one member of the team shapes the work.

One Person Starts, the Entire Team Finishes

Section titled “One Person Starts, the Entire Team Finishes”

If your team works independently, it’s possible someone has time before starting “their” next story. You can see the possible value stream maps for collaborative and siloed teams in Measure Cycle Time, Not Velocity. If your team does that, maybe a team member can start to shape the work on their own.

I said start and not finish. Because to finish shaping, one person needs the rest of the team. Otherwise, that person needs to explain to the rest of the team the state of their thinking.

I don’t like this for several reasons:

Most of my clients cannot use this option, either. However, there are more options, such as brainstorming/workshopping all the problems to solve.

Workshop (Brainstorm) the Problems to Solve as a Team

Section titled “Workshop (Brainstorm) the Problems to Solve as a Team”

If your team only has senior people available to it for a short time, use them to workshop the problems to solve. I outlined a previous version of this thinking in Alternatives for Agile and Lean Roadmapping: Part 1, Think in Feature Sets.

This allows the team to decide where to experiment and where to offer incremental value. The team can do this because they clarify the problems the feature sets solves for which users. When we solve problems for customers, we can consider which of the product minimums we want. Those minimums might clarify where we want to experiment and where we want to just move in a straightforward path. (See the image at the top of this post.

When people start thinking in feature sets, they can often decompose the work into features that allows the team to make incremental progress. That’s what a spike does.

Spike the Work as a Team

Section titled “Spike the Work as a Team”

I wrote an article a few years ago called Need to Learn More About the Work You’re Doing? Spike It!. A team-based spike allows the team to learn together and decide what to do about the code and tests when they are done.

Today, the team might use an AI of some sort to rapidly experiment and validate the idea behind the feature. (I’m still quite skeptical of long-lived AI-developed code, but you might not be as suspicious as I am.)

The point is to learn about the problems, as a team. Then, implement small increments of value, as a team. Then, assess what the customers say, as a team.

Yes, I said “as a team” several times because the speed of the team’s learning matters much more than any one person. Assuming you care about both the quality of the product and the speed of development.

Shape Work for Better Backlogs

Section titled “Shape Work for Better Backlogs”

Many product backlogs require shaping at some point in their development. Sometimes, that shaping offers a way to see the interim steps toward the next product deliverable.

But in my experience, sometimes that shaping cannot deliver the “right answer” because the team needs to experiment.

I prefer team-based approaches to shaping so no one has to “catch anyone up.” Instead, the team is all on the same page, all the time. The WIP stays manageable. And with any luck, the cycle time decreases.

However, all of that assumes the team has the necessary skills to do the work.

The Entire Backlog Series

Section titled “The Entire Backlog Series”