GarethTownsend.Info

Small Stories Are Better Stories

Any first year computer science student should be able to explain the divide and conquer algorithm, why it is important, and when to use it.

But how many developers apply it to their software engineering practices?

Stories

Agile developers work with the concept of stories. Essentially these are short explanations of what someone should be able to do with the software once the story is implemented.

A user should be able to manage their account.

This story is vague, open ended and typical of client feature requests.

Before estimating this story, you’re going to need to get some fine grained detail into it. After talking with your client you might end up with the following:

Managing their account consists of changing their name, updating their contact details, changing their profile picture, resetting their password and swapping between username/password and open-id for authentication.

Now you have enough information to estimate this story, you know what the client means by “manage their account”.

You might come up with an estimate of say 100 points.

This example is contrived but if every story your client sends you follows this same process you’re heading straight for a world of pain.

The Effect of Large Stories on Iterations

So you start work on your iteration with 10 large stories with your team and half way through you’re looking at the number of stories you’ve sent to your client for testing.

That number is zero and you’re starting to feel a bit stressed out. It’s ok though because by the end of the day 5 stories have moved into the testing phase.

You move on to the rest of the stories in the iteration and your client gets started testing the stories you’ve completed. Some of them pass and others get sent back because something is not quite right.

The cumulative effect of multiple large stories is an exponential story completeness graph.

The Effect of Large Stories on Developers

Working on the same story for a long period of time is painful. As a developer you feel like you’re climbing a mountain that just keeps getting bigger.

You’re not sure where the top is, and sometimes you think you’ve reached it, but as it turns out you’ve forgotten something and you’re not quite at the top.

The effect on the team is that everyone goes through this same journey every iteration.

Your client experiences the same in reverse. They sit around waiting to climb the mountain, and they wait, and then bang, they’re expected to be half way up the mountain almost instantly.

Divide and Conquer for Happiness

Large stories can often be broken down into smaller stories. In fact you already did this when estimating your stories. But you finished one step before you should have.

You should have split the original story into multiple smaller ones:

A user should be able to change their name.

A user should be able to change their contact details.

A user should be able to change their profile picture.

A user should be able to change their password.

A user should be able to switch between username/password and openid for authentication.

Each one of these stories is smaller, has easier to meet acceptance criteria and will be finished earlier.

Your client will love you because they don’t spend half their time sitting around and waiting for stories to test.

The developers in your team will love you because instead of climbing one massive mountain, they are climbing 5 mounds.

Everyone feels like they are constantly moving forwards through the iteration.

The story completeness graph moves from being exponential to linear.

That’s a much more positive graph to have hanging on your office wall.