In the previous post (Breaking up a large User Story into smaller parts – Part 1), we talked about trying to break down the User Story into smaller more discrete parts, such as separating the positive and the negative parts of the logic into separate User Stories. In this post, we will talk about more such ways of breaking down User Stories, including some methods that are not really recommended.
– One method that could be used for splitting is breaking down the desired functionality along the lines of the various layers of the software. For example, if you have to define the User Story for a retail bank user login mechanism, then you could define the functionality in terms of different application layers – the functionality dealing with the entry mechanism on a web page (including validations that the entry box was not empty, both User name and password had been entered, and other such validations on the web page), then validations at the middle layer and the database layer. The middle layer had some more business logic defined, while the database layer would fetch data related to the user. This could check whether the account existed, but the account had been closed or made inactive, or fetch the correct information for the user.
Now, it would be simple to break up the logic into these different application layers for the purpose of dividing into different User Stories, and you would find a number of people agreeing to this logic. However, consider the following fact. The desire for User Stories is that each User Story is supposed to also deliver some Business value, and if you break up the design into these application layer based User Stories, you would find that there is no Business value to be defined even when you accept the completion of these User Stories. One of the big problems with proceeding on this separation into User Stories is because it makes a fundamental assumption that all of these User Stories will be completed during the Sprint, in order that the work be demoed. However, this is an assumption that may not hold up and if for example, part of the User Story related to the Database layer is not completed, the entire set of User Stories cannot be demoed.
Further, another big problem in trying this split across the application layers is that when the team reaches a crunch period, and some User Story needs to be put on a lower priority. When such a point is reached, and the Product Owner will need to make a decision, there is really no good way of making a choice. You cannot make a choice across Application Layers when you don’t have enough granularity to be able to make such a choice, and it is like putting the Product Owner in a hard place. After all, how can you decide that you will need to drop the middle layer and still expect the application to be able to demo properly.
Won’t it have been easier to have tried to split the entire application layers vertically; that is by defining a User Story that just had the successful completion of login; another one that catered to the case where the user had entered wrong data and the web page did some validation and threw an error; another case where the database threw back the error that the banking account of the user had been put into inactive mode and some messaging needs to be put in front, and so on. Now, if there is some kind of time or resource crunch, then the Product Owner can put some of these negative cases User Stories into a lower priority or move to the next Sprint. There still will be a demo of application functionality, but some of the validations would have been moved to the next Sprint.
Read more on this same topic (Breaking up a large User Story into smaller parts (contd..))