In the previous post (Breaking up a large User Story into smaller parts (contd..)), we talked about using a functionality based method for breaking down the Use Cases into multiple smaller User Cases, rather than trying to break it down by Application Layers, even if Application Layers seems easier to do, or even seems more logical. This post will explore the concept of trying to help users in terms of breaking down User Stories, more the principles of how to do so rather than a list of steps that could be run. This is subjective to some degree, one cannot have bullet points for this sort of thing.
One way to determine how to break a User Story down into multiple User Stories is by extracting the various negative / error conditions into separate User Stories so that those could be prioritized appropriately and also ensure that the estimation for those User Stories is smaller and more discrete. Now, you would like to think that the Product Owner would be able to do all these conditions; but it is better to realize that the team can play a great role in all this. It is ideal if the Product Owner does a series of discussions with the team about the User Story and the team is able to spend some time on working through the Product Owner. If this does happen, there is a high chance that the team will be able to separate some more conditions from the User Story, and these can be wrapped into separate User Stories, where the Product Owner can do the required prioritization, and even move some of these User Stories into later Sprints.
Let us consider an example. We have a small feature for an ecommerce web site, where the User clicks on the Shopping Cart icon and it is supposed to show the User a list of items in the cart; at this point, the future workflow would be for the user to either do more shopping, or click on the button for Checkout of the cart. So the Product Owner creates a User Story relating to the User Clicking on the Cart icon for fetching the items of the cart. Conditions that would be implicit (and these would be separate User Stories) include checking for time-out, and for throwing an error that there were no items in the cart. However, when the discussion happened with the team, some more conditions came up:
– There have been price changes for the items in the cart, and subsequent alterations needed to be informed to the User about these changes (and there can be multiple User Stories for the same)
– The connection to the Database failed at the time that the User was trying this transaction, and an appropriate error message for this had to be passed to the error handler
– The User deactivated their login in the time period before the cart button was clicked, and this case also needs to be handled in a separate error handler system
Like these, when the team does discussions, many additional User Stories could be thrown up; some of them would be more important and some less important. How this helps though is that when the Product Owner has defined a User Story, the team will produce the feature for the User Story and also ensure that logic for the feature is all handled as a part of the actual work. If some of the logic can be extracted from the User Story before the work is started, it will ensure that the team has more information, and the Product Owner can do more prioritization.
