Many Scrum Teams use User Stories as a technique for creating their Product Backlog Items (PBIs). But when the teams bring big stories to the Sprint, this causes lots of problems. The common recommendation is to slice stories so that the team can take 6-10 of them to the Sprint. Let's discuss in detail why this is so important.
Fast feedback
A team that works with small stories and finishes them in 1-3 days can get feedback from the Product Owner and stakeholders without waiting till the end of the Sprint. If your Definition of Done (DoD) includes acceptance testing (UAT), then this is very important.
Fast mistake correction
It is important to note that the developer remembers the code he has written in the last 24 hours perfectly well. If during this time he receives any comments from other team members or some issues found, he will be able to correct things way faster.
Postponing less valuable work
When stories are properly sliced into a few smaller ones, the most valuable stories can go to the top and the rest may go to the bottom of the Product Backlog. The Scrum Team does not waste any time on performing something that has less value from the Product Owner’s perspective.
Better forecasts
Let’s assume the Development Team has an average velocity of 17 story points per Sprint. They usually work with big stories of 8 and 13 story points. There is a big chance that by the end of the Sprint, one of these stories will not be finished. Thus, the velocity fluctuates greatly from Sprint to Sprint (8 to 21 and even more).
If the Development Team had small stories, say, of 3 story points each, the fluctuations would be less noticeable. Consequently, the Development Team could come up with a more reliable forecast during the Sprint Planning and release planning for the Product Owner.
More trust
The Development team, which stably finishes on average the same number of stories from Sprint to Sprint, becomes more predictable for the Product Owner and stakeholders. This helps establish an atmosphere of trust.
Better spirit
Finishing 6-10 User Stories in each Sprint strengthens the Development Team’s spirit, because people like the feeling of accomplishment. Think about it, which are your favorite football matches – those that end with a score of 0:0 or 3:2?
Saving time on estimations
If the Development Team delivers 6-10 small stories during a Sprint, it is very likely that those are approximately equal in size. This means that over time the Development Team will not have to estimate each story individually, just calculate the number of them.
Risk mitigation
Better slicing means a more detailed analysis of the items. Thus, a big chance that the Development Team identifies and mitigates risks that otherwise would have surfaced in the upcoming Sprint. As they say, being forewarned is being forearmed.
Better distribution of work within the Sprint
I often meet the Development Teams that get overloaded at the end of each Sprint. This problem is very complex, but a finer slicing of stories is one of the ways of dealing with it. Small stories in the Sprint lead to better parallelization of the work and the Development Team's performance usually improves.
Key Thoughts of This Article
-
Bringing big stories into a Sprint causes lots of problems.
-
Fine slicing of stories allows you to get feedback and fix mistakes faster, postpone less valuable work, increase trust and raise team spirit, save time on estimates, better mitigate risks and improve performance.
To read