The following article is a guest post to Zephyr from Rodney West, Senior Consultant and the Editorial Director at Isos Technology. Isos Technology is a partner of Zephyr and is the market leader in solving complex enterprise challenges from Agile adoption and QA to DevOps and they help teams improve quality and speed delivery.
Bloated user stories. Anyone who has spent any time on Agile teams has come across them. As a high-level jumping off point for estimation and development, a user story should contain just enough information to summarize requirements and little more. But requirements can be complicated. It is easy to fall into the trap of rolling too many requirements into a single story.
When you come across a bloated user story, don’t be afraid to split it up. Before you do, however, you need to answer a few questions.
What does it buy you?
Splitting up a user story should buy your Agile project something. The whole reason you are using Agile is to get more done with fewer resources in a quicker time. If splitting up the story doesn’t buy you anything, then it is little more than process for process sake.
- Reduction of idle time: In Agile projects, all team members should have ample tasks to productively fill their time. Bloated user stories easily create situations where team members are in long wait states. Smaller user stories may help reduce idle time by shifting team members to user stories where they can be immediately utilized.
- Overall resourcing: This applies to both team members and server resources. The full team complement and servers required for a larger user story may be greater than what is needed for smaller stories. This can result in resource contention scenarios, especially in organizations where resources are shared across projects and teams. Smaller scenarios will reduce “locks” on these resources.
- Partial delivery: Continuous delivery of usable products and features is one of the most appealing features of Agile development. Bloated user stories take longer to develop. Smaller user stories promote more frequent delivery, staying truer to the principles of Agile development.
- Parallel development: Though bloated user stories don’t prevent parallel development from a structural perspective, they may from a psychological one. It is often times easier to identify tasks that can be done in parallel when they are contained in separate stores. Smaller user stories will help your teams identify which tasks can be developed in parallel and which are dependent on each other.
Will it hurt?
Of course splitting user stories may also cause you some pain. You need to decide if this offsets what you might gain.
- Overly granular: The new user stories shouldn’t be overly granular. The point of user stories is as a starting off point. Heavy implementation details will inhibit the process. Details will come during design and development.
- Overcomplicates the system: You don’t want your split user stories to add additional complexity to the system. If splitting a user story is going to require a sprint at the beginning just to add the scaffolding needed to support new user stories and another sprint on the backend to remove the scaffolding, this may not be acceptable. You don’t want to have to redo significant parts of the system involved in the user story for each smaller user story.
- Increased time and resource costs: The purpose of splitting user stories is to make requirements more manageable and improve resource allocation and utilization. You should be very careful about the addition of time and resource costs due to splitting up a user story. Ideally, splitting a user story should reduce these. If these increase, you need to carefully look at how you are breaking down the user stores.
Should you do it?
Splitting user stories is a careful balancing act. You need to make sure what you are gaining outweighs the cost. The more often you go through the process, the more of an intuitive feel you will acquire for when a user story is becoming bloated, and when it should be split. Just remember, the process is called Agile for a reason, and your stories shouldn’t be set in stone. At the end of the day, your clients care about results, not your processes. Craft your stories accordingly and split them up when needed.