Should a user story fit entirely into one sprint?
What are the benefits of having Stories smaller than one iteration? Why should you split bigger user stories? And why divide stories into even smaller pieces? What is the value of stories one-fifth the size of a sprint?
Generally, completing one or more user stories or tasks to the DoD state in each sprint allows you to comply with the Scrum principle of incrementality. But what does that mean, and why should you follow this principle?
Working in increments has many benefits, and many of them are listed below.
Definitions
Formally, increment and definition of done are Scrum artifacts. Neither user stories nor tasks are mentioned in the Scrum guide; however, both can be part of the product and sprint backlogs, as well as defects and other elements. All of them are called by the general term “backlog items.” In the Agile practitioners’ community, the following distinction is often accepted:
- A feature is a larger piece of functionality that delivers a concrete meaningful user value.
- A user story is a smaller piece of functionality that does not necessarily have to deliver value, but each one should deliver something meaningful, testable, and be an observable step toward delivering value.
- A task is usually not of value to the user. It can be purely technical, and invisible from the outside.
- A subtask is a specific work that needs to be done to implement a story or task.
The recommendations below are most useful for user stories, but they are also applicable to tasks.
Success is more probable
By dividing stories into smaller ones, you automatically conduct a more detailed analysis of them and consider them more nuanced. As a result, you efficiently reduce the risk of failure, meaning that the probability of successfully completing the stories increases since their estimations become more accurate.
Planning is easier
If when splitting, you strive for the maximum independence of the smaller stories (see the “independent” characteristic in the list of criteria for good stories, called INVEST), then you can implement stories in the desired order and different combinations, becoming more adaptive to stakeholder requests and unexpected changes.
Since you can implement independent stories in any order, iteration planning is significantly simplified–no need for network diagrams and sequencing. If you’ve already implemented integrations with the components of other teams in the early iterations, then there will be fewer dependencies and synchronization points, and planning the subsequent iterations will become even less complex and more manageable. There will be more action alignment with other people and teams, and the waiting time for other teams to complete work on each story will decrease.
Risk management is easier
Next, you will be able to handle risks faster. For instance, if dependencies are the most significant risk, you can implement integrations early, reducing the number of dependencies on adjacent teams. If product hypotheses are the greatest risk, you can check them in early iterations. If the riskiest thing is a new technology, you can start with it.
Story splitting helps you take the biggest risk first.
If unforeseen circumstances occur, only one story out of several planned for the sprint would be blocked. Otherwise, the only big one you barely crammed into the iteration gets blocked, which means the entire sprint’s scope is endangered.
Similarly, if changes are needed, such changes will affect specific small backlog items rather than a big one entirely, and other stories can safely move on.
All of these lead to a reduction of risks and uncertainties, a more accurate forecast for the iteration, and a more feasible plan.
A more accurate forecast and more stories are implemented per sprint.
Predictability is higher
Smaller story sizes will allow you to plan a more significant number of them and complete most of them. And the probability of success–creating a DoD increment by the end of the iteration–gets closer to 100%.
Able to adapt on the go
As an additional benefit, when the team learns to quickly divide large stories into small ones, they can easily do this when needed during the sprint. This approach is practical when the team does not have time to implement the whole story. They can quickly divide it to have time to implement the more important half. The team becomes more adaptive/agile.
You can decompose during the sprint if you do not have time to complete the whole story.
Quality is higher
The developer remembers the code of the last X-hours well. The smaller the job, the better the developer retains the written code, which means they will search for the root cause and fix defects faster.
The product is better
Also, according to Scrum, at the end of the sprint, the story, like any other element of the backlog, must meet the definition of done–the definition of an item’s readiness. With these criteria, the team learns to complete each backlog item to the DoD state rather than hoarding a set of various items that are almost ready. This will allow them to “deliver working software frequently.”
The team will be able to show the finished story during the sprint without waiting for its end, to get comments, and will still have time to adapt the result before the sprint review and increment demonstration. Further, this entailed frequent feedback leads to a product that meets customers’ and users’ needs.
“Maximizing the amount of work not done”
Small stories allow you to prioritize more precisely, deliver the most important stories faster, and postpone the less important ones.
Let’s say you have ABCDE backlog items, and you divide A into A1, A2, and A3. After analyzing priorities; it turns out that the correct order is A1, B, C, A2, D, E, and A3 is dropped far down the backlog. With this correct order, you could save time and effort and implement BCDE faster.
Prioritize better. If you divide A into A1, A2, and A3, it may turn out that the correct order would be A1, B, C, A2, D, and E, with A3 going down the backlog.
More precise prioritization lets you follow the Lean principle of reducing overproduction wastes, and one of the 12 principles of the “Manifesto for Agile Software Development,” i.e. the art of maximizing the amount of work not done, thereby saving the budget and increasing the ROI of the team’s efforts.
More frequent delivery to the production environment will let you get new knowledge more often, check the product performance, and get early feedback from users.
All this helps towards having a greater product corresponding to the customers’ and users’ high-quality expectations. Eventually, the product becomes more and more economically successful.
Stakeholders are happier
According to Scrum, only DoD results can be demonstrated at the sprint review. Since the team is now more likely to create an enhanced working version of the product (increment) by the end of each iteration, the team can demonstrate the product’s real functionality and not just the reporting slides during the sprint review. This increases stakeholder satisfaction.
“Deliver working software frequently”
Small jobs are performed faster. Customers and users will be able to give their feedback on completed stories during the iteration, and not only during the demonstration at the end of the sprint. Of course, if their requests jeopardize the sprint goal and significantly increase the amount of work, the query can be placed in the product backlog and postponed until the next sprint. If the backlog item is brought to the DoD state, and customers are satisfied with the result, it may be delivered to the production environment before the end of the sprint, and even several times during the iteration.
Frequent and early delivery of value in the form of new, ready-made, high-quality functionality to the production environment allows users to regularly receive value in small portions, and the gradual learning of new features makes exhaustive user training documentation unnecessary.
Next, it allows your business to benefit from additional users and early sales, making your product economically successful.
The team is greater
A close deadline, which usually entails an unbalanced workload and team exhaustion in fire-fighting mode during the last quarter of the timeline, is now divided into several smaller, usually two-week ones. Therefore, the level of destructive stress is reduced for the team members.
Bringing several small backlog items scheduled for a sprint to the DoD state increases the sense of completion and the feeling of high pace, which contributes to strengthening trust with stakeholders. Furthermore, completeness and speed, together with predictability and stability, improve team morale.
Following the principles of Lean and Agile, the team doesn’t waste time and effort on less important things. Small chunks of work go through the software development process faster, especially when striving for focus and “One-piece flow.” (Read scrum values.) Therefore, the workload of employees during the sprint becomes more balanced by competencies (the team, of course, strives for interchangeability and T-shaping, but not always at that state from the very beginning). And it logically follows that the overload on testers and developers at the end of the iteration is lower and rarely happens. A non-overloaded team with a low level of destructive stress usually turns into a happy team.
Completing a backlog item to the DoD state makes the team more adaptive to changing their priorities and scope of work. Ultimately, a team that delivers some working functionality every sprint–maybe not 100% of the plan, but at least a working part of it– is a hot team; and hot teams create great products.
Downside risk
With all these myriad advantages, I want to warn you. If you split stories too diligently and too zealously they may become too small, i.e. not “whole.” They become more like subtasks.
As I mentioned in the definitions section, stories do not have to deliver value, that is what features are for, but each one should deliver something meaningful, testable, and be an observable step toward delivering value. For example, a job written according to a user story template that says, “As the app, I am able to connect to the database” would be too small, and even though it is technically testable, and formally looks like a story, it does not really move the feature forward in an observable way. That would, however, be a good subtask of some other user story.
Summary
Breaking down large stories into smaller ones can lead to a variety of benefits. By focusing on smaller, well-thought-out stories, estimates become more accurate and forecasts become more feasible. This reduces the risk of failure and increases the probability of a successful sprint. Additionally, small stories can be prioritized more reasonably, allowing the team to tackle the most challenging risks first and ultimately save on budget.
With smaller, independent backlog items, planning becomes easier, leading to better alignment and less waiting time. Smaller tasks can also be completed and fixed faster, which helps to keep the overall workflow moving smoothly. The ability to break down large stories into smaller chunks during a sprint can also aid in more efficient problem-solving.
Two-week deadlines can also help to alleviate stress and increase team morale by decreasing the overall workload. A higher level of predictability and frequent production deliveries can improve trust with stakeholders, resulting in better relationships.
Smaller stories also provide opportunities for more frequent delivery to the production and bring in new knowledge, including performance issues and early user feedback. This helps the team to become more adaptable and ultimately leads to a better product that meets customers’ needs as well as greater economic success.
In conclusion
More satisfied, adaptive, and hot teams that deliver new high-quality DoD state functionality every two weeks or more often result in more satisfied users and stakeholders. Together, this results in successful products and sustainable businesses.
