Lightweight User Stories for effective Agile & DevOps Adoption
- Posted by Yomna Anwar
- On June 7, 2021
Constructing lightweight user stories has proven time and time again their effectiveness in delivering high-quality value quickly in agile environments. In this blog, we will discuss different techniques on how to slice or break down larger user stories into smaller more bite-size user stories. Breaking down larger user stories into smaller ones help deliver value quicker, promotes innovation from the team, avoids confusion, limits gaps and helps in prioritization.
WHY BREAKDOWN USER STORIES
Breaking down user stories from larger ones to smaller ones has many benefits to both the team and the customer. Tackling more bite-size user stories will ensure:
- Quicker delivery of value to the customer and in turn provide the team with feedback to be taken into consideration for future implementation.
- Promotes innovation within the team, since the team will have smaller stories, they will be able to focus more on innovative ways to deliver the best value to the customer.
- Avoids confusion and limits gaps, smaller stories are usually more to the point, therefore there are little to no assumptions in the story thus reducing any confusion or gaps.
- Helps in prioritization, having smaller sized stories will help the customer and the team set clear priorities across the backlog.
WHEN TO BREAK DOWN USER STORIES
User stories should be broken down when they can if it makes sense. What that statement means is if a story can be broken down using one or more of the techniques mentioned below, then it should probably be broken down. Stories should fit comfortably into a sprint, meaning, you shouldn’t have a story that would take up an entire sprint. Ideally, a story should take 1-3 days and not more, this will allow the team to work on and deliver multiple stories at the end of the sprint thus maximizing the value of the sprint deliverables to the customer.
This brings us to the next questions when to STOP breaking down stories. You should stop breaking down stories when it no longer fits within the INVEST criteria (refer to our previous blog for more details on writing good user stories). You should also stop if it no longer makes sense, so if a story is already small enough to fit within the 1-3 day window while adhering to the INVEST guidelines then there shouldn’t be a reason to split it further. If the story starts to look more like a task than a story then that is an indicator that you have broken down the original story too much.
HOW TO BREAK DOWN USER STORIES
Richard Lawrence came up with some of the following techniques that one might use to break down a bigger user story into smaller ones. Not all of them will be applicable to every user story, you check which technique or group of techniques work best:
1- Workflow:
It is best to come up with a thin slice across the entire workflow and break that down into stories. This technique is also known as coming up with the MVP (Minimum Viable Product). The helps remove unessential steps in the workflow and deliver the customer with the maximum possible value with the least amount of possible work.
| Original | As a customer, I can select the method of payment upon checkout |
| Broken Down | – As a customer, I can choose to pay by credit card – As a customer, I can choose to pay by cash on delivery – As a customer, I can choose to pay through pay pal |
2- Simple vs Complex
Keep your stories simple, if you find yourself asking “what about x ?”, “how would you handle y ?” then it’s probably time to stop and start splitting. If your story inherently holds a complex scenario, it might be better to break down that complex user story into multiple simpler user stories.
| Original | As a customer, I can use the application to reserve a flight |
| Broken Down | – As a customer, I can use the application to reserve a one-way flight – As a customer, I can use the application to reserve a round trip flight – As a customer, I can use the application to reserve a multi-destination flight |
3- Business Rule
Some people are comfortable with coming up with the user story then adding all the business rules to be applied in the acceptance criteria for that story. This might be better in terms of backlog management as it could help keep the backlog less cluttered, however, this might add overhead to the development team. So to keep the focus on delivering the maximum value it would be best to divide up the business rules in the acceptance criteria into separate user stories (when applicable)
| Original | As a customer, I can reserve a flight by selecting the travel dates |
| Broken Down | – As a customer, I can reserve a flight by selecting strict travel dates – As a customer, I can reserve a flight by selecting flexible travel dates – As a customer, I can reserve a flight by selecting flights during weekends only |
4- Happy vs Unhappy
Sometimes you find yourself adding all validations (unhappy) scenarios to the story itself. This automatically makes the story larger and more complex to develop. Separating the happy scenario from the unhappy ones ensures that the customer will be able to at least get the maximum value from the happy scenario and allows you to get feedback to be taken into consideration when working on the unhappy scenarios.
| Original | As an anonymous user, I can sign up so that I can start using the services |
| Broken Down | – As an anonymous user I can sign up so that I can start using the services – As an anonymous user I cannot sign up if I am under 18 – As an anonymous user I cannot sign up if I am in an unsupported country |
5- Major effort
This technique is best used when there is some groundwork to be done that will facilitate the development of other scenarios. For example, if you’re working on multiple services that use the same form it might be best for you to have that as a separate user story so that it would be reused in the other services.
6- Operations (CRUD)
If you find that your story can be broken down using the basic CRUD operations (Create, Read, Update, Delete) you should do that.
| Original | As a registered user I can manage multiple profiles |
| Broken Down | – As a registered user I can create a new profile – As a registered user I can edit an existing profile – As a registered user I can delete an existing profile – As a registered user I can view all my profiles |
7- Variations in Data
This technique can be used if your story has multiple types of data. You can then split the story into smaller stories, each smaller story to hold the information for a specific type of data.
| Original | As a manager, I can access KPI reports for my employees |
| Broken Down | – As a manager, I can view KPI reports for my employees by quarter – As a manager, I can view KPI reports for my employees by team – As a manager, I can view KPI reports for my employees by goals |
8- Variations in interface/Platform/Roles
This technique might not always be applicable or might be applicable in very limited scenarios. You can split up your stories based on the interface/platform so you could start delivering to the customer a working piece of software that might not yet be compatible across all interfaces or platforms.
| Original | As a user, I can access the application from all my platforms |
| Broken Down | – As a user, I can access the application from my web browser – As a user, I can access the application from my windows application – As a user, I can access the application from my iOS application – As a user, I can access the application from the mobile application |
9- System Qualities
Lastly, if your story holds system qualities that are good to have it’s best to divide them up into different stories.
| Original | This may not necessarily have an original story to be broken down, but can be extracted from several acceptance criteria |
| Broken Down | – As a user, I should see a spinner when the page is loading so that I know that the page is not unresponsive – As a system admin, I can view the audit trail so that I can help resolve issues |
VERTICAL SLICING
If you google vertical slicing the picture of a sliced cake floods your results page. Vertical slicing is a technique of delivery that helps get you valuable feedback in shorter intervals to be taken into consideration when working on the next small deliverable. The reason vertical slicing is usually explained using a layered cake is that, if you work on creating all the layers of a cake then the customer has some changes they want to be implemented. It will cost you more time and effort to either fix the existing cake (which anyone that has baked a multi-tiered cake will tell you is messy) or you’ll have to bake an entirely new cake. However, if for example (and by the way this is where the cake analogy falls apart) you only bake slices of the cake and then get feedback on that then build the next slice and so on you are more likely to achieve the requirements custom-tailored to the needs of the customer based on incremental feedback,
PITFALLS WHEN BREAKING DOWN USER STORIES
Once you have broken down a user story, what happens to the original? Do you still need to keep track of it? Theoretically, if you break down the story correctly without missing any points from the original then it becomes useless.
Should I turn it into an epic? Do not get too caught up in labels and grouping. Only group using a single layer usually epics. You can turn the original story into an epic, however, if you do that with every single broken down story then breaking down stories has not added much value. If you want to use epics, it is best if you group multiple broken down stories to limit the number of epics you have.
Never slice a story based on development or testing efforts. When you do that you are diminishing the value of the story since the customer does not care about development or testing efforts, they only care about value.
Do not split all your stories at once, this can sometimes cause you to do double or triple the effort since requirements are a constantly changing thing. So if you break down all your user stories at once if some of the original ones change you will have to break down the new requirement again while also getting rid of the original ones. So it is best to break down enough user stories to be a sprint or 2 ahead of the development team, this will give the team a nice backlog to choose from during the sprint planning.
CONCLUSION
In conclusion, it is up to you to choose the technique you wish to apply to your larger user story to break it down. Since applying multiple techniques to the same user story will probably result in different smaller stories, so you choose whichever technique fits best for your team and project.
To know more, please check our webinar “Lightweight User Stories for effective Agile & DevOps Adoption“.
