Some Thoughts on Agile Planning

Agile Math

The basic math of team based agile is pretty simple. You can slice it several ways, but at the end of the day, one of these three basic formulas has to hold true. It’s all about time, cost, and scope… you get to decide which two constraints you want to lock, but then you have to derive the third.

1. backlog size / velocity = duration
2. duration * velocity = backlog size
3. backlog size / duration = velocity

I generally suggest that agile is all about fixing time and cost, and deriving scope… but it doesn’t have to be that way. Feel free to derive time based on a fixed backlog and known velocity. You can even derive a planning velocity based on fixed scope and time. This one is the most risky, so be prepared to measure, adjust, and negotiate as the plan unfolds.

Limiting WIP

But here is the rub… when a team has too much work to do, and not enough time to do it, there is a cognitive dissonance between the messages of agile and what they see on the ground. We can say all day long that the PO gets to decide the “what” and the team gets to decide “how” and “how much”… but if management is fixing all three variables, the team isn’t going to buy in.

Rushing the Backlog

Generally, here is what I ask from management out of the gate… give us three sprints to help the team come up with a backlog and establish a velocity, afterwards we’ll see what we have and decide how to proceed further. We’ll start by doing just enough backlog planning to identify a sprint or two worth of work, and get the team working to establish a velocity.

While the team begins work to establish their velocity, the PO aggressively moves to create the backlog. Almost never do I see a PO that can create a backlog all by themselves. Very often we need Product Managers, Architects, and Analysts to paint the complete picture. More often than not, I’ll ask these folks to work full time for as long as takes to get the backlog together.

I’ve got one PO team that has been at it 8 weeks just to get ahead of the team, and define the release. Initially the PO team is focused on feeding the teams high value, high risk stories… but as the backlog emerges we start rounding out the app. If all goes well, after several sprints we have a decent idea of what we have to build and the rate at which the team can complete the work.

At that point, we apply one of our three formulas, baseline the plan, and go.

Emergence or Convergence

How far ahead of the team you need to be largely depends on your business goals for the release. If you are highly uncertain about what you need to build, smaller backlogs are probably better, and the release planning process can be more nimble. Trying to predict stuff you just don’t know is waste. In this case, agile is helping support an emergent outcome.

Not all companies are going for an emergent outcome… some want stability and predictability. In these cases, the PO team needs to plan further ahead of the team and adjust as the product is developed. The better we know where we are going, and what it is going to take to get there, the further out we can plan the backlog, and the more certain we can be about outcomes. Here agile is supporting a convergent outcome with focus on risk reduction and predictability.

One of the biggest problems I see with teams new to agile, is that they act as if they are going for stability and predictability, when their product requires an emergent approach. Either requirements are not well understood or because of high technical risk or a ton of unknowns around how to implement. Either way, you have to act as if the project is emergent until you gain enough knowledge to establish a more predictable plan.

Not Knowing What You Don’t Know

I’ve met a few teams lately where everyone is new and unfamiliar with the product and the code base. How do you set a schedule in this environment? The short answer is… you don’t. It’s okay not to know, but it’s not okay not to know forever. In this case, you better have a plan to get it figured out fast… It’s not reasonable to indefinitely ask the business to invest with no strategy for getting to done.