User Stories: Divide and Conquer!
Smaller user stories pay off
16 December 2015
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
A user story represents a small piece of business value that a team can deliver in an iteration. However, the length of the story can sometimes hinder the development team from getting the story into production. In my experience, the story should be as short as possible so that the development team can work independently, the product increment can be brought to the product owner for review as soon as possible, and the development team can then deliver it to production as soon as possible. The "short" in "short stories" means short in workload, not in words.
The longer the user story gets, the more difficult it is for the development team to deliver, which makes for a difficult continuous integration. Of course, in some cases, a long user story cannot be divided into smaller tasks so that two or three development team members can divide it among themselves. Instead, only one person can work on it, so it will take a lot of time to deliver. But this is not the ideal situation.
User stories should also be independent of each other. This means that one development team member shouldn't wait for another to implement his or her story. Any dependency will create a bottleneck that can block the development team from achieving its sprint goals.
Another problem with long user stories is that they make it difficult to estimate and plan the effort to implement them. When it's time for iteration planning, you should be able to define, code, and test the story within the iteration.
Suppose you are developing a user dashboard that includes a user's profile picture and cover picture. Both images will be uploaded to Amazon S3. If you write a long story for the profile picture, which will automatically include the Amazon S3 feature, then the upload-cover-photo story has to wait to be able to use that same feature.
My key takeaway has been, "the shorter the stories, the better the outcomes."
Current rating: 4.5 (4 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.