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

Comments

[Anil Apte]

Good points. Similar thoughts can be found at:
http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29
>>
The INVEST mnemonic is frequently used as a reminder of the characteristics of a good quality user story.
>>

[ecommerce website developers]

The eighth point static vs dynamic is a good point i can say because most of the users and visitors don't like to visit static web pages ,..most of them prefer dynamic website ex: Like implementing flash on the website

[BlogFront]

Hi Jack,

BlogFront.org is committed to uphold the quality standards of blogging. We strive to maintain and promote only the most credible blogs in their respective fields.

Spam blogs or "splogs" has been a problem for some time now and people are getting confused about which blog to trust.

We would like to thank you for maintaining such a reputable blog. We know that it takes time, effort and commitment to keep such a blog and as such, we have added your blog as one of the top Agile blogs.

You can see your blog listed here: http://blogfront.org/agile

You can also claim your BlogFront Top Blogs badge at http://blogfront.org/badges/agile

Thank you for keeping your blog credible. Let's keep the blog revolution alive!

Maria Blanchard
BlogFront.org
Blog Revolucion

[joomla extensions]

I definitely agree with this , I just don't rely any thing, It is good to think and do the best which is possible.

[joomla extensions]

I definitely agree with this , I just don't rely any thing, It is good to think and do the best which is possible.

[Watch Carnage Online Free]

I really loved reading your blog. It was very well authored and easy to understand. Unlike additional blogs I have read which are really not good. I also found your posts very interesting. In fact after reading, I had to go show it to my friend and he enjoyed it as well!

[Register domain name]

Wonderful site I will post a link to this page on my blog Thanks to sharing