Feed on

Give most of your effort to the most important story, a little to less important stories, and none at all to unimportant stories.

To me, the most amazing thing about the urgency principle is how I ever managed to live without it.

As an individual, it reminds me to stop screwing around doing stuff that is anything less than the most important thing. This works for me whether I am coaching, coding, writing, blogging, or doing home repair.

The quantity of empirical data that says multi-tasking is inefficient staggers a researcher’s mind. No one advocates doing two things at the same time. It follows, then, that if I’m not doing two things at once, I have to choose which one of those two is most important and do that one.

As For The Team

As a team, the urgency premise is all about sorting user stories – software development for the business – into a literal stack, where the most important story is at the top and the least important at the bottom, and every story between is more important than the one below it and less important than the one above it.

Many companies bucketize their work. They pick some small integer, usually 4, and divide all their stories into those buckets. They’re usually called “Must-Have”, “Should-Have”, “Like-To-Have”, and “Optional”. This technique has the rather remarkable property that it does not work in any way. Every customer voice in such an organization knows that the only way to get something actually done is to get it into Must-Have, and even that isn’t always enough to guarantee its inclusion. Optional is always empty, and Like-To-Have has one or two token stories.

Coaching Urgency

The key to coaching urgency successfully is to help the team understand why story-size is so important. Granularity is key, here. We want them to understand why we shrink the granularity of stories as small as we possibly can.

Take a look at these features (large stories) sorted by importance:

It’s pretty easy here to say that we should do our work 1-2-3-4, yes?

Same Order, Smaller Stories

But what if we take those same four features, but this time broken into smaller stories. Everything in the figure below that isn’t in light blue is lost value. If we follow the 1-2-3-4 strategy, we’re going to implement B and C before we implement D, and that’s clearly sub-optimal.

The Actual Optimal Order

The final figure below shows the same work as before, this time sorted absolutely by value. Do you see that by splitting and re-sorting we have dramatically changed our implementation order? So will your customer team.

The shape here is called the diminishing value curve. Producing stories A-D-B-G-E-H-F-J-C-I-K-L is far better suited as a strategy. If that’s not obvious, let’s take the same diagram and add a shipping date:

There’s room here for another whole conversation about the shape of a user-story. Soon, soon. For now, this will do:

Choose One Story, Hammer It. Repeat

Leave a Reply

AWSOM Powered