In my previous post (Breaking up a large User Story into smaller parts (contd..)), we talked about how to break down the User story into smaller slices that still provide benefits to the User. This breakup would also enable the Product Owner to be able to look at much smaller sections of User Stories and be able to set the right priority for each of these User Stories. In this post, will talk about some of the benefits of trying to break down the User Stories into smaller User Stories. This kind of push to break down the User Stories into smaller such stories would have some benefits, otherwise there would be no benefit to doing this breakdown.
– When the User Stories are made smaller, it is easier for the developers to provide a more accurate estimate for these User Stories. This increased accuracy also helps the Product Owner to be more sure of the number of features that are planned for the Sprint. Variances in these estimates and actual delivery can seriously affect the actual functionality that is delivered in a Sprint.
– The Velocity measurement for the Sprints becomes more easily trackable and less problems for the team to work through.
– When a larger User Story is broken down into smaller User Stories through this process, it helps the Product Owner to make a better determination of what needs to be done in the current Sprint and what can moved to future Sprints, or need not be done at all.
– Having small items to do ensures that the Product Owner and other stakeholders can view progress in terms of actual deliverables (this one is strictly not a very point, since one does not like to encourage that the teams are on watch all the time, but it may be required in some specific case)
– Making User Stories smaller ensures that clarity on what is needed to be done is much better with the team responsible for delivering the User Story being on the same page to a higher degree. When User Stories are larger, it is more probable that there are points where there is not complete clarity on the actual workflow, and these can cause problems later on in the cycle.
– When one is working closely with the end users, it makes sense to be able to have much smaller sections for feedback to the end user, so that if there are any changes required, the amount of rework needed would be lesser. Also, it makes the end user more comfortable when they see that features are getting done and being available for reviewing.
– When User Stories are smaller, it makes the team feel that they are delivering more, and that they are not stuck in the same feature for lengthier periods of time.
– During the Daily Scrum, instead of team members trying to estimate how much they have done of the large User Stories, it makes the morale of the team much higher to see features being done on a regular basis.
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.
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..))
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..))