User Stories: How small is too small? #scrum #xp #agile

I like a User Story to be precise and target a specific functionality, a Use Case or a logical vertical of a Use Case. This means that a finely scoped task of 2 or 3 hours could be called small. It also depends at what time in the SCRUM backlog a certain User Story is implemented for it to be a small or large User Story.

At the beginning of any development project all User Stories are large, they include many additional variables everything from setting up the initial design patterns, to drastic refactoring to allow for stackable functionality. This means that a task which might take 2/3 hours once there is a working vertical to build on could take considerably longer when everything needs to be build from scratch. Ron Jeffries – SCRUM God – says in a recent conversation on the SCRUM Development list that he “expect[s] more defects when using bulk mode.” And later adds that “I expect that larger stories will be more poorly tested. If team breaks down to roughly uniform small stories, and some are tested while small, others rolled back up, I expect that more defects will escape to field from the large.” Ron and I agree that a more detailed User Story will lead to a better product, although slicing User Stories down to the level tasks – which may be better suited to unit tests – makes the SCRUM cycle more cumbersome.

Let’s take as a starting base a product for which there has been a reasonable amount of development, as we are more likely to encounter a small User Story here. A current project I have is building a digital safe, most of the features have already been build and we need to replace the current mock service for mail notifications. For the notifications which will be added we will generate notifications on creation, updating, deletion and for a number of additional reasons – which I won’t explain here. For this we could have a User Story which states:

“As a user I want to be informed of updates to my digital safe by mail, so I can verify my data is secured”

or I can create a User Story for each of the tasks create, delete and update. In this case the different options have slightly different workflows; for update it includes versioning; for delete it includes recovery possibilities which are offered in the mail. So I can add more finely slice and add the User Stories:

“As a user I want to be able to see content of changes in my mail, so I can verify my data is secured”

“As a user I want to be able to revert deletions instantly from my mail, so I can ensure my data is secured”

Read more articles on Agile, SCRUM or XP…

In both cases these are merely changes to the content body of the mail, and I don’t add any value by adding these tasks as User Stories. Kelly – All About Agile – suggests that we “write test confirmations on the back of the card for each one.”

In my opinion if it mostly duplicates and existing User Story and you can write a unit test to test that instance, it can be included in a larger User Story.

Sources: Ron Jeffries, Alan Dayley, Charles Bradley, Kelly (All About Agile)