What’s in a Story – Breaking things down

When I think back on my Scrum experiences I keep coming to the same conclusion - that the mechanics behind “Stories” has to be the most important aspect of the process. If your “Stories” are properly “designed” then you have the best shot at succeeding with Scrum.

So when I say “designed” what do I really mean?

Let me explain ….

For starters while I believe that the format of the Story is important (I wrote about this some time back that the format is not the most important thing though) when I say design I mean the careful thought given to how the stories are broken down.

Essentially, the smaller your stories are the more chance you have of succeeding. Most of the Agile thought-leaders (especially from the XP camp) are recommending small equally sized one or two day stories.

Trust me creating equally sized stories is pretty hard to do. If you can get them equally sized then there’s all sorts of benefits including tracking just by counting stories which is very easy to do.

However as I am sure you know by now I am not religious about things like this. So while I don’t necessarily prescribe to one size fits all, I do believe wholeheartedly in smaller stories are better.

Breaking down stories is hard too. I hear it all the time, “it’s not possible to break this story down any further”. But there’s always a way so in this blog I am going to give you some neat ideas on how to break stories down further.

But let me start with DON’T BREAK STORIES DOWN BASED ON ARCHITECTURE. i.e. It’s not good to implement just the GUI layer or just the DB layer. It’s important to maintain a thin slice of the feature across all layers if at all possible.

So what are some of the better ways to split?

1. CRUD – or rather Create, Edit and Delete

So if your Story is say as a sales person, I’d like to be able to create, edit and delete an account from the CRM system, then you could first do Create, then in another Story you do Edit and in another you do Delete.

2. Acceptance test criteria.

Don’t know about you but before we begin any Sprint, all the acceptance test criteria are defined and agreed to up-front for every Story. One way to pare things down is to split the story into separate Stories for each of the test criteria.

3. GUI Screens

Another way is to split the functionality by Screen boundaries or by paring down the number of elements implemented on the screen

4. Validation

You could of course choose to do data validation in the next story, that wouldn’t be such a bad thing

5. Scalability and Performance

You could choose to get the Story working, but then later refactor it for scalability or performance although this is somewhat risky. But sometimes we spend more time iterating through the look and feel of something than we do on performance so better to see what it looks like first than to see it working for thousands of simultaneous users.

6. Stubs

You could choose to Stub out certain functionality by creating stubs to simulate functionality

7. API/GUI

You could get the API functioning correctly first and returning the correct data and then later hook it up to the GUI – although I don’t think this is necessarily the best approach

8. Static vs Dynamic

You could implement the functionality using static data in one Story and then later implement the dynamic parts to the story

9. Error handling

You could choose to add the error handling in a second Story

I stopped short of ten as I am sure there are lots more ways. Perhaps you can help me fill in the rest with some of your experiences.

Thanks for reading.

Jack