Product Backlog Items (PBIs) or user stories should be small. Small stories provide focus for the team and gives members the flexibility to adjust and adapt to changes. The larger the story, the higher the risk of team members getting lost in the details and creating bottlenecks as members are busy and unavailable to collaborate and help other teammates. This increases the risk of reaching the end of the Sprint with a lot of PBIs still in progress and failing to produce a quality Product Increment.
So the question is how small is small? A good rule of thumb is that no user story should take longer to complete than half the duration of the Sprint. That is in a 2 weeks Sprint for example, no user story should take longer than 1 week to complete. And this is the exception not the norm. Maybe 1 user story can be this large. Most user stories should be a lot smaller than that, typically in the half day to 2 day time frame. This increases the likely hood of accomplishing the Sprint goal by ensuring that stories are getting completed throughout the Sprint and providing visibility and ongoing feedback on the team’s progress.
To learn more about user stories, check out the entire Art of Storytelling Series:
- What is a User Story?
- Top 5 Advantages of User Stories
- The 6 Attributes of Effective User Stories – INVEST
- Top 3 Reasons to Split a User Story
- What’s the Right Size for a User Story
- Top 5 Techniques for Splitting a User Story
- What’s the Most Important Part of a User Story?
- 9 User Story Smells and Anti-patterns
- The Art of Storytelling – User Story Smells and Anti-patterns Presentation
Reference and recommend resource: User Stories Applied by Mike Cohn
