What is the point of breaking down user stories?

This may seem like a strange question coming from an Agile Coach, but what I want to do is to try to make the reasons less mushy and abstract. Many is the time when discussing (and usually disagreeing on) the need to carry out a certain “Agile” activity that the actual reasons can seem to carry very little weight in the heat of the real world.

I believe this to be a very real problem. I think that it leads many Agile Coaches, Scrum Masters, etc to switch into “preachy mode” – the worst reason you can give for doing something is “because that’s Agile”. If you find yourself justifying something on those lines, then I would suggest that you have turned “Agile” into dogma – which means you have lost the central purpose implicit in Agile principles: only do stuff if it makes sense to do it!

So, back to the question – seriously, what is the point of breaking down user stories? I don’t think that the answer is necessarily trivial. Let’s start with some stock answers which can be understood easily through simple logic:

it provides clarity about the “scope” of the work
it makes it easier to see progress
it provides a better flow of work
the smaller the piece of self-contained work is, the quicker it is, the sooner that testing can be done
with a shorter cycle time, it means that there is a smaller chance of interference and interdependency

OK, but suppose you have some monster piece of refactoring work to do. It may be difficult to break up. There may be many unknowns. As you work on it, more and more things will come to light, so the size of the work is not known. As it is refactoring, it is not adding any new functionality. The work could drag on for a whole sprint and maybe more.

It is in a situation like this where the reasons for breaking up the work start to flounder:

“We have to break it up because it will be bigger than a sprint.”
“So?”
“Erm, you have to get things done within a sprint”
“Why?”
“Erm, because we are doing Scrum”
BZZZZZ! There it is, the justification which says “just do it because it’s Agile”. OUT! YOU LOSE!

In a situation like this, the developers are thinking: “Here is a large heap of dung which we have to shovel – if we break it up, we still have to shovel the whole pile! So what is the point of wasting time breaking it up?”

This entry was posted in Agile. Bookmark the permalink.