Happy Friday!

"I need to get a better sense of our group's capacity," is a common request clients have of me. While answering this question is not really very interesting, I think the existence of the request is and the topic of today's email.

One reason this request comes up is that ever since agile ate the world everyone had to start using agile tools and techniques to answer age-old questions. Unfortunately, many of these agile tools and techniques are purposefully regularly incapable of providing satisfactory answers.

For example, the request above would typically receive a "That's what we use velocity and story points for" response. There's a problem, which is that story points are an abstract measure, and velocity is an average of that abstract measure. You might as well measure capacity in the sighs and eye-rolls per team.

Fine, but why not just use the old ways of measuring capacity? Here's where I think things get interesting. I'm about to say something that is really a narrow way to look at situations like this, and there are many other angles.

When we look at the choice to use a technique or tool, we sometimes go through a checklist that might go like this:

1. Do I know how to use the technique?
2. Is the technique consistent with my principles?
3. Is the technique consistent with my values?

When one of these questions receives a no for an answer, we typically will stop using whatever tool or technique exists. So you might know how to use a tool or technique, but if it goes against your principles or values, you will likely stop.

What's this got to do with capacity? Well, as I've said before, there are lots of ways to answer this question, but groups get stuck with it not because of a tool or technique problem but because they believe they will be violating a newer established set of principles and values.

In the world of agile there is a huge emphasis on teams as a unit of measure compared to individuals, and a huge emphasis that sprinting and short timeboxes are the engine for everything. We can go further and say that priority is better than formal planning, and sprints are better than dates. These beliefs act as principals in this hierarchy.

So now we could measure capacity a traditional way by ideal hours or keyboard hours and such, but then this veers backward against our principles about individuals and planning. So we feel we cannot use these techniques.

However, the trick here isn't to look at these tools or techniques as bad but rather to ask how you can use them while remaining consistent with principles. For example, can I use a traditional capacity technique while remaining consistent that the team is a more cohesive unit to inspect and that we will still inspect and adapt each sprint? I bet you can.

While I personally don't use work breakdown charts or Gantt charts, they are useful for many folks, and you can absolutely use them in an agile environment. We can use them to create transparency about where we are and where we think we're going. We can adjust them based on what we see each sprint. These actions would be consistent with many groups' principles while also answering important questions at a strategic level in the business.

So next time it feels like you're trapped with a question that you used to be able to answer, take a look at the values and principles that feel conflicted and then ask how you can do the necessary work but in a principled way.

Sincerely,

Ryan