The Agile Daily Standup - AgileDad

Does Every User Story Have To Be Small? - Mike Cohn

Sep 17, 2024

In this engaging discussion, Mike Cohn, a leading expert in agile methodologies and user story writing, tackles the common belief that every user story must be small. He explains the benefits of larger user stories, particularly in the early stages of product development when not all requirements are known. Cohn emphasizes the importance of flexibility in story sizing and suggests that stories can grow and shrink alongside project needs. He also highlights techniques like time-boxed spikes for effective story management.

05:25

Creator website

Episode guests

Mike Cohn

AI Summary

AI Chapters

Episode notes

Podcast summary created with Snipd AI

Quick takeaways

Small user stories are essential for Agile success, providing clearer focus and manageable backlogs during sprint planning and execution.

Larger stories can be valuable in early development stages, maintaining backlog clarity while allowing for details to emerge over time.

Deep dives

The Importance of Small User Stories

Small user stories are crucial for success in Agile methodologies, facilitating easier consumption by teams and promoting organizational success. It is recommended that user stories be kept small or extra small for inclusion in a sprint to prevent the pitfalls of larger, more unwieldy tasks. Larger stories may hinder clarity and create a backlog that is difficult to manage during iterations. By approaching user stories with this guideline, teams can maintain focus and ensure a more efficient workflow and manageable sprints.

The Balance of User Story Sizing in Agile Development

5min

Does Every User Story Have To Be Small?

Small user stories are essential to success with agile. When it’s time to bring stories into an iteration, I always want them to be small.
But larger stories have their place as well–especially for something you're not going to work on imminently.
Suppose you have just begun work on a new product that will include a set of reports. Because this is a new product, there is nothing to be gained by writing a bunch of small user stories around each one of those reports at this point, especially since you don't yet even know all of the reports that will be needed.
At this stage of the project, having one big reporting story rather than a bunch of little ones keeps the size of the backlog more manageable. You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.
Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything. Early in a project, that's probably not true. New reports will be identified and some that are asked for initially may not be necessary.
Don’t fall into the trap of thinking every story needs to be small from the beginning. They don’t. Instead, plan for stories to shrink in size and grow in detail as they move closer to being brought into a sprint. For most teams, this will happen during the product backlog refinement meeting one or two sprints before the iteration planning where they’ll be considered.
Letting timing dictate story size will help you succeed with user stories and with agile,

How to connect with AgileDad:

- [website] https://www.agiledad.com/

- [instagram] https://www.instagram.com/agile_coach/

- [facebook] https://www.facebook.com/RealAgileDad/

- [Linkedin] https://www.linkedin.com/in/leehenson/