It seems like one of the most obvious statements to make; after all, when you are getting any kind of instructions on the Scrum methodology, one of THE things said is to ensure that the User Stories are short, defining descriptive tasks. It is paramount that the User Story does not describe a large process or function, which covers multiple steps or workflows. However, in many cases, the reason why a User Story needs to be short is not described clearly, and is pretty important to understand why (including some reasons about what happens when the User Story tend to be long).
Many teams have veered around to a process for keeping User Stories short. As an example, some teams have started using Flash Cards (or similar palm sized cards for User Stories – with the condition that the User Story should be able to fit onto a card in normal writing; if it is larger, then it needs to be examined to see how it can be broken down further). But this does not mean that the written User Story is condensed in any way, the written User Story should focus on the regular items – it should define the need for the User, the workflow for the User, and the benefits for the User. Any problems or negative cases should be defined in separate User Stories (and it makes sense when you think about it, since an error is a different functionality and hence should be covered in a separate User Story).
Think deeply about the User Story that has been defined by the Product Owner. If the User Story tries to cover multiple items in the User Story (for example, the User Story could have the words for an error check for date field in the screen “check for value being blank OR value being negative numbers”. Now, when you see the words “AND” or “OR” or something similar that takes 2 tasks, then you know that the User Story could have been broken down into more smaller, more discrete parts. When the team starts evaluating the User Stories, before the User Stories are committed for a Sprint and estimation is started, there needs to be discussion to see how the User Stories can be broken down further into smaller more discrete parts. The Product Owner needs to realize that there may be cases where the User Stories can be refined down further, and not feel upset or offended when something like this does happen during discussion (it may seem logical to think that a right thinking Product Owner would not feel offended (even if it to a small degree), but it can happen).
Another benefit of trying to break down a large User Story into smaller more discrete stories is that such an effort can split the User Story and reveal some tasks that are not so important. Suppose the validation of the User Entry data for a site is broken down into individual errors. When this is done, it is possible that some of the validations end up with a lower priority (for example, the validation for not being able to enter alphabets is of a much higher priority than the user being able to enter special characters (since that would require multiple key entry)). Doing so gives the Scrum team and the Product Owner the ability to save overall effort by focusing on the tasks that are higher priority and de-focusing on the ones that are less important.
There are more reasons for making the User Stories as discrete as possible, as well as the methods for reducing the size as possible. In the next post, will cover more details.
Read the next part of this article (Breaking up a large User Story into smaller parts (contd..))
