How to Reduce Planning Time to Create Better Goals at All Levels, Part 2

MPD, product ownership / By / / agile, agile planning, agile project management, project vision, WIP

In How Product Goals Make it Easier to Create Sprint Goals and Reduce Feature Factories, Part 1, I started responding to Tom's interview question. Now that we've dealt with the feature factory problem, it's time to address planning time.

Here's the question again:

“The product owner and dev team cannot decide on a sprint goal, even after hours of discussion. They (the team) feel that the tasks for the sprint are too varied to manage to a single sprint goal. What should the Scrum Master do?”

My second objection was that the discussion went on for hours.

Let's start with the reason we plan anything in an agile approach.

Reasons for Agile Planning

If we have a product goal or vision, we can say, “Here's what we want to accomplish for this next bit of time and work.” There's a reason I say, “next bit.” All agile approaches limit WIP (Work in Progress).

If you use iterations, you might create a sprint goal and then limit the work based on what you think you can accomplish in the next iteration. I'm not big on estimation for software-only teams. I'm more likely to recommend the ideas of right-sizing and counting stories. (See How to Right-Size Your Stories for Better Predictability for more information.)

In flow, you might limit the WIP for the entire team, and maybe within columns. (Overloaded teams often need to limit the WIP in any of the various states.)

Regardless of how we limit WIP, most of us like a look-ahead to see what we will do over the next few days to a couple of week. I do, because I want to make sure I'm fulfilling my desired objectives. (That's how the product vision intersects with low-level planning.)

Many of us like some planning. But we often need to plan much less than we do.

Necessary Planning

Iteration Contents ChartHow much do we need to plan? Answer these questions for your team if you use sprints in some way:

  1. How long are your iterations? I assume they are two, three, or four weeks.
  2. Measure your cycle time in either of two ways: Use a value stream map as in Measure Cycle Time, Not Velocity, or count the number of things your team accomplishes in a given week. (See the Iteration Contents chart in this post to see what you might count.) That's your back-of-the-napkin cycle time.
  3. Based on either measurement, answer this question: What does your team get done in a given week? (Yes, you should use a time series as in How to Predict When the Team Will Complete a Specific Backlog Item, Part 1 to precisely answer this question, but we don't need precision right now. We need an accurate number, which is often a range.

Now, count the number of items your team, in general, can finish in a week. Multiply that number by the number of weeks in the iteration. That's the number of things you need to plan. That's it. No more.

For example, if your team can generally complete four stories and two defects in one week, multiply that by two for a two-week iteration. If your team can finish eight stories and four defects in two weeks, that's all they need to plan before the iteration starts. That's twelve items to rank and discuss.

If your team is more like the teams I teach and coach, they can finish one or two things in a given week. For a two-week sprint, they only need to address the top two items in the product backlog. Two items.

So what was that team doing in hours of planning?

Assess Why Planning Takes Hours

Some teams get stuck in planning because:

  • The team is missing a piece of critical information and someone wants them to estimate the size. Instead, the product leader should assess the value of each item. (Yes, I know, some people like to do the shorter work first, but why not use Cost of Delay and release something people really want?
  • No one can agree on the ranking.
  • There is inadequate facilitation, either on the part of the product leader, the Scrum Master, or the people on the team.

I like to ask the product leader: What is the most valuable item right now? What one item/story/problem will make the most difference to our business right now? (For more details, see the ideas in One Quick Way to Start to Manage Your Project Portfolio and apply them to the backlog.)

When I ask the “one item” question, people often have one idea. Then, they have trouble with numbers two, three, and four. So, don't rank numbers two, three, and four.

You don't have to “fill up” or push-plan a sprint. You can choose just one item, finish that, and then go back for more and plan again.

I would rather deliver something in a couple of days, and because we learned from it, replan, not plan in advance.

Reduce Planning Time When You Plan Fewer Items

When I teach this “what one item” to Scrum teams, everyone tends to recoil in horror. They feel as if they can't plan for a “full” iteration because they don't have “everything” for the next iteration. But sometimes, we don't know what we need for this next iteration. We can use the idea of “how little” for planning instead of “how much can we shove into a sprint.”

Here's how this works:

When we choose one item, we can finesse both the ranking and the inadequate facilitation. (I'll return to that later.) Even better, the team has one goal and that goal serves the product goal.

I'll address the issue of the product owner not being part of the team in the next installment.

The Series:

Leave a Comment

Your email address will not be published. Required fields are marked *