A #NoEstimates tool: The slicing meeting, replacing estimation meetings while creating shared understanding

Before we start, I’d like to thank to Neil Killick and Woody  Zuill for inspiring this technique with their work.

Sit down. Let’s estimate

This is not a good start of a meeting for many of us. Asking for estimates may be an easy thing to do, but going through the process of estimating Stories or Epics is never easy or quick.

When the project starts is when we know the least about it. Estimating the work to be done at this point seems to be, at best, a mine-field of unvalidated assumptions. At worse, estimating work at the start of the project may lead to making commitments that will later prove too costly.

Here’s a concrete, step by step, suggestion of what to do instead: slice the work by understanding its complexity.

The slicing and simplification meeting: or how to get to an MVP in 5 minutes or less

When a story is presented ask simple questions like:

How many people do we need to collaborate with to complete this work: 1-5 or 5-10 or more?

The answer to this question gives us an indication as to the social complexity associated with the work. To slice this work down into an acceptable level ask: how can we slice the work so that we can deliver something of value while only needing to collaborate and coordinate with less than 5 people outside the team?

If that question sounds too difficult for a particular Story, then ask:

how can we deliver something of value towards this Story while only collaborating and coordinating with 10 people or less?

Order stories by complexity to assess risk and slicing opportunities

Next, order the Stories by technical complexity. As a silent exercise, ask the team to order the stories in order of technical complexity from left (most complex) to the right (least complex).

Because technical complexity can be defined in many ways, here’s one possible set of questions to ask yourself while (silently) assessing the technical complexity of a Story:

• Do we need to change multiple files or modules? (+1 if you answer yes)
• Do we need to refactor one or more modules while implementing this Story? (+1 if you answer yes)
• Do we need to rerun the performance tests after implementing this Story? (+1 if you answer yes)
• Do we need to integrate with previously known to be problematic modules or API’s? (+1 if you answer yes)
• Do we need to have a design meeting with another team to be able to implement this Story? (+1 if you answer yes)

A practical way to slice a technically complex Story is to try to resolve one or more of the previous questions so that the complexity is reduced. For example, how could you implement the same valuable functionality without needing to integrate with previously known to be problematic modules?

By reducing each of the technical risks we are effectively slicing our Stories to reduce risk, and therefore reducing their technical complexity.

Heuristics, not rules

The ideas presented above are heuristics, not immutable rules. In practice, we want to nudge our definitions of stories towards less social complexity and/or less technical complexity. While in some cases you will not be able to avoid certain aspects of technical or social complexity, we know we will benefit in the cases where we are able to slice our stories into smaller increments with less complexity.

With time you will get the hang of how much complexity is OK to accept in your organization, but as a starting point, try to practice slicing stories down to the lowest complexity categories

A challenge

What questions would you ask to help you define both technical and social complexity for a single Story?

Photo credit: Photo by Phong Nguyen