Written by Anthony de Wouters,
Jan 14, 2020
Not all user stories are equal. Some may be larger and more complicated than others. The challenge in agile delivery is to keep stories at the right size. That way, they are easily understood and delivered. Those that are too large pose a risk. Wherever possible, you should break them down into smaller, more manageable pieces. In this blog, I will explore factors that might lead to user stories being too 'large'?
Sizing user stories - how large is large.
Let us start by discussing what 'large' means. Different teams have different definitions of large. If two independent teams use the same sizing technique to evaluate the same user story, you would probably get two different results. One group may consider a user story large and assign 10 points to it, while the other may say that it is too big and thus worth 13 points. The numbers are not significant because you cannot compare different teams' sizes. Each group evolved and calibrated over time a method and scale for sizing. The main point here is that each team has established a unique approach to determine which number is too large for them. For example, my current team considers a story large if it is 20 points or more. The moment we encounter a user story of that size, we have committed to no matter what, breaking it down into smaller, more manageable chunks. Based on our experience, stories of that size are too big to complete within a sprint period and are hazardous to predictable quality delivery.
So, what can delivery teams or business areas do to reduce the size of user stories? After all, the smaller the story, the easier the delivery, which in turn means more stories can be completed.
- Dependencies on external factors
Some user stories depend on other teams or features. It can tangle or snare features making them larger and more convoluted. You should remove or reduce dependencies as best as possible. Stand-alone stories are more manageable and easier to implement. When reviewing a user story, you should highlight and systematically remove any existing dependencies. It will help simplify the story and reduce its size.
- Complexity of feature or solution
The complexity of a user story will drive up its size. The agile manifesto clearly states that implementing more straightforward solutions results in better outcomes. Avoid over-engineering and treat it as wasted effort. High complexity is often a sound basis for splitting a single story into several parts. Take the case of a front-end user interface that processes information and provides an outcome to a user. If this story is too large for a team, break it down into three more granular features, such as the validation of the inputs, the processing of the information and finally the aesthetics of the User interface.
- Team skills and experience
Team skills and experience
Not all teams contain the perfect skillset to solve a specific problem. If a team lacks particular expertise, such as database creation and configuration, stories of that nature will consistently be estimated larger than those that fall more naturally within the team's skillset, until the team becomes cross-functional. In another scenario, perhaps user stories require an in-depth knowledge of specific business rules. If the team doesn't have a business representative or business analyst to assist, then those types of stories will be sized larger. The solution would be to understand the nature of the stories and to either construct a team that better matches the skills requirements or source specialists to support and supplement the team over that period. This approach will not only reduce the story's size and complexity but also encourage skill transfer within the group.
- Uncertain or ambiguous requirements
Uncertain or ambiguous requirements.
The delivery team must be clear about the story requirements. If a story is ambiguous, it will more often than not, result in inflated story points. Ensure that all outstanding decisions are made in advance to avoid time wasted on troubleshooting or confirming the solutions mid-sprint.
- Deployment process or path to production
The path to production or process of releasing a feature has a significant bearing on the size of the user story. If a feature requires a complicated deployment process on various environments, this additional burden will weigh down and slow the development progress. A delivery team should have a clear and well-established deployment process, required permissions and tools. For newer initiatives, involve experts, like DevOps practitioners, who can support the team with creating a pattern for releasing code. Once they establish the process, stories can be delivered faster and with reduced overheads.
When faced with a choice of delivering smaller stories versus fewer large stories, I would choose smaller stories every time. Larger stories can often feel like an iceberg. Only the tip of a problem is visible above the water while what lies beneath may be more hazardous and unknown. Although the explained 5 factors are by no means an exhaustive list, working on any of them will undoubtedly help you and your team create better solutions with fewer risks to delivery.
