« Puppy #2 Identified| Main | On Losing »

Livin' the 20/40 Rule

| | Comments (0)
Telescope
Who is looking at whom?

It never fails. As soon as I explain the 20-40 rule (teams can only really process and work 20-40 items at a time -- whether those items are user stories, business rules, domain classes, whatever) I get the same question.

"But what if my team has a lot to do? Surely every team can't work just with a list of 20-40 items. That's crazy. How about building the Space Shuttle? Or fixing all the bugs in Windows Vista? This 20-40 rule once-and-for-all shows that you're just talking academically and not practically."

So let's take it a step at a time. How can the team control the amount of stories/domain classes/supplemental items to an arbitrary limit of 40 or so?

First I'm going to explain how, then I'm going to change the way you think. (Hopefully)

First off, what's a backlog if not a list of future behavior the system should perform? Balance the checkbook; visit space station, compose letters, chat with friends, etc. These are in that old verb-noun format (add an actor if your user stories start to get lonely).

Both parts of this can be expressed in various levels of detail. Indeed, "Do Stuff" is the huge, mother-of-all use cases. Every technology project you ever worked on, at some level of abstraction, was just making some technology that would "do stuff"

Likewise, every kind of model you ever wrote could collapse into just one box with the word "System" written on it. The System -- it does stuff.

If that sounds silly, I apologize. But it should show you that your choice of language -- the details of your verbs and nouns, controls the number of items you have to process. It's up to you. I can take the next space shuttle project and label it "do stuff". Or I can take it and list ten thousand noun-verb phrases that the system will enable. I can diagram it as simply "Space Shuttle" or I can diagram ten million parts and how they all fit together. I am in control.

It works the other way too. No matter how simple the project is, you can expand it out. I could write "Balance Checkbok" as the user story I want my system to enable. Or I could write a thousand user stories, all talking about things like memory allocation, user interfaces, CPU timing, etc. It's easy to do.

Let's take the same principle and look at our supplemental list. Supplementals are just blanket statements about the system not particularly associated with any one user story. "System must be built with .NET 12.7" is a good example of a supplemental. In this case, we could stick with that simple item, or we could make a list of a thousand items found in .NET 12.7 that must be used. It's up to us.

Which reminds me of something I learned a few years ago.

When I was a teenager, barely 17, I had a lot of philosophical questions. What's truth? Why are we here? What's the meaning of life? Stuff like that. I know it seems frivolous now, but at the time those questions really bugged me. They eventually caused me to leave the religion of my youth and find my own way through life.

Viktor Frankl
Viktor Frankl
How come old guys always show up in these columns?


A few years back, I was reading "Man's Search For Meaning", a book which most readers in the United States voted as one of the top ten most important books in English. (Read it.)

Frankl was a psychiatrist who was imprisoned in a death camp in World War II. As such, he got to see thousands of people go through conditions that it would be unethical to ever put people through. As a result of his experience, he created a field of psychiatry called logo therapy.

He also took on the question "What's the meaning of life?"

"It did not really matter what we expected from life, but rather what life expected from us. We needed to stop asking about the meaning of life, and instead to think of ourselves as those who were being questioned by life—daily and hourly. Our answer must consist, not in talk and meditation, but in right action and in right conduct. Life ultimately means taking the responsibility to find the right answer to its problems and to fulfill the tasks which it constantly sets for each individual."

You see, I was approaching the question the wrong way. I was thinking here I was, born here in this big world, and the big world owed me an explanation for what was going on -- how I fit in. Instead, life has persisted for eons -- and will persist for eons more. I'm just a tiny speck of nothingness on a big ball of rock spinning around some backwater yellow star. I wasn't the one asking the questions here. Life was the one asking the questions, and the main question it had for me was "what about you has value?"

Each and every day, I was presented with questions. Questions about ethics, honesty, helping people, standards. Life was asking the questions, and I'd better be coming up with some good answers.

I had the telescope pointed backwards. Once I oriented it the right way, things started making a lot more sense.

Magic Hat


How can the team control the number of items to an arbitrary 20-40 items? The team doesn't control the number of items -- the team controls the language used to describe the problem. The language controls the number of items.

The size of the backlog has nothing to do with how big the project is -- if you've been following along you should realize that by now. So the number of items in a backlog does not determine scope. It's the language of the items. The 20-40 rule is not about the number of backlog items -- it's about forcing the team to think at a level that it can work at, no matter what the size of the problem. Things get scoped in and out of projects just like always, but by keeping the size of stories consistent and the size of user stories consistent, scoping and "chunking" is done in an intelligent manner.

How do we know if the problem is too big for the project? Once again, it goes back to the language. If, when we get to those 20-40 magical items, we're talking about users interacting with a computer system? We're ready to start making a computer system. But if we're talking about how various large-scale components work with each other (as would happen if we started down the road to build a space shuttle)? Then our work product is to compose, prioritize, synthesize, and componentize our problem into smaller components/ programs.

Agile is never about hard rules, it is about ideals and doing the best we can to reach them. The 20-40 "rule" is a gimmick. It keeps your stories at a consistent level, your thinking clear, and your problem-solving abilities at maximum effectiveness. It's the same work either way, so why make your life miserable and your project run longer than it should?

Leave a comment

About this Entry

This page contains a single entry by Daniel published on October 23, 2008 3:13 PM.

Puppy #2 Identified was the previous entry in this blog.

On Losing is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Powered by Movable Type 4.23-en
Daniel Markham