Large user stories (features) may pose a challenge even for teams that are quite efficient in producing high-quality releases consisting of small-to-medium size user stories. By large, we mean stories that take a considerable time for specification and/or development (more than a week for example) or have a high degree of complexity. Oftentimes, the same patterns that are so useful with smaller user stories are applied to their large cousins, most notably the story being developed by a single developer. By their size longer development times are oftentimes simply accepted resulting in schedule risk, the risk of not making it in time.
Let’s take a comprehensive look at the consequences of this approach.
Single Assignment: an all-in approach
The decision that a single developer is responsible for a large user story is a multi-bet that the developer will
- finish in time for the target release date
- not get sick during development
- make the right decisions on the way and not be biased (“confirmation bias”)
- raise his hand in time whenever he or she needs help
- will avoid scope bloating
- be around and available next time when a similar topic in the domain is to be implemented (since he is in the know)
It should be evident from this list that the risks associated with these bets should not be accepted.
Note. In legacy industries with a strong background in traditional approaches, the approach to large user stories is widespread. Even after years of having seemingly switched to agile approaches, the belief that it is desirable that every task needs to be assigned to a single person that can be tracked it’s still prevalent. With small user stories this goes unnoticed and it’s ironic that the real power of agile is not harnessed.
So, let’s outline how to better deal with the large user stories.
Collaborate and Decide
Since a single developer is apparently not the solution the obvious alternative are two or more developers. Let’s call them a feature crew. The size and the setup (experts, skill levels) of the crew should be appropriate. In that decision one should weigh in the estimated effort, complexity and possibly technical exploration required.
After getting acquainted with a story it should be split not into tasks but into smaller stories. If business analysts or testers are part of the process, they should join in a story splitting session. Outcome of this session is a set of user stories and a shared understanding of the scope and context.
It should be noted that the smaller user stories need not to be viable in the sense that one would attempt to release them individually. This misunderstanding is often a mental block when slicing large user stories . To be clear, it is only required that the user stories are testable and provide value, please see: INVEST. If the user stories have different priorities or some are even “icing on the cake” this should be noted. Any visualization will be helpful, be it sticking index cards to a physical board or drawing tickets on a digital whiteboard.
Once the feature crew has built up sufficient knowledge to start work establishing a dedicated chat might be helpful for distributed teams.
Another important aspect is decision making. Large user stories are more likely than their smaller cousins to require decisions to be made, sometimes over an architectural nature. This topic will be covered in another blog.
Positive effects
Large user stories will be finished earlier since more developers are involved. Not making target dates is less likely. We thus see a reduced schedule risk.
Rework due to wrong decisions is less likely since more people have participated in the decision process.
Know how has been spread to more team members than with a single assignment approach. The team will be more capable of developing similar user stories (or extensions) in the future.
