In this episode, Chris Sims shares four techniques to split your user stories to make them smaller, more manageable, and to help draw out details.
After listening to this episode, you'll understand:
- The problems big user stories can cause
- How big your user stories should be
- Why splitting stories helps create a shared understanding
- How just four splitting techniques apply to almost all stories
Show Notes
User stories that are too big are a common problem. Big user stories make it difficult for the team to complete the story within the iteration and they often make impediments less visible.
How big should a user story be? It depends.
Near-term user stories at the top of your backlog should be small enough to be completed within a day or two. Items further down on your backlog can be larger and less refined.
The farther out a story is, the bigger it can be because you don’t want to over invest in stories that may change. This is the power of doing just enough just in time.
To get near-term stories into our state that’s ready for the team to execute upon, the team should meet weekly to review and refine the backlog. This refinement includes splitting stories to make sure they are small enough and adding detail around the acceptance criteria.
Splitting stories not only creates smaller stories, it also generates more detail about the user story through a conversation of how that story changes when split.
While there are dozens of ways to split user stories, knowing how to use just a handful of approaches will help you in most situations.
Chris Sims recommends four approaches to splitting stories:
- Split by conjunctions and connector words
- By analyzing generic words
- Using acceptance criteria
- Through timeline analysis
Splitting Conjunctions and Connector Words
Within the narrative portion of the user story (most commonly the “As a . . . I want . . . So that” portion), look for conjunctions and connector words such as and, or, but, with, etc.
You can often split the story at those connector words and have two smaller stories. For example, the user story:
“As an online banking customer, I want to be able to view my account and make updates so that my account has the correct information”
can be split into
“As an online banking customer I want to be able to view my account information so that I can verify information is correct”
and
“As an online banking customer I want to be able to make updates to my account information to correct any erroneous information”
Look For Generic Words
Another way to split user stories is to elaborate on generic words used in the narrative portion. Generic words are terms that are very general and broad.
You can identify generic words by asking yourself “What kinds of those are there?” Example:
“As a user of the system, I want to be able to maintain my account details . . . “
For the above statement we can ask “what different types of users of the system are there?’ There may be users with administrative access, users with regular access, logging users, users who are not logged in, etc.
You can create a separate user story for each of these user types. This not only makes user story smaller, it also helps you to have a more detailed discussion about the specific needs of a user.
The word “maintain” is also a generic word. There may be many different actions as part of maintaining an account including updating name, updating e-mail address, updating mailing address, adding upgrades users, and even deleting the account.
This approach allows you to incrementally build a solution that addresses different needs.
Use Acceptance Criteria
Chris’ third way of splitting user stories is by acceptance criteria. Acceptance criteria are the pass fail tests that specify the scope of the story and tell you when it’s done.
If the user story has four acceptance criteria, teams will often split it by breaking it into identical user stories each with only a few of the acceptance criteria. Chris’ approach is a bit different.
Chris recommends looking at the acceptance criteria to determine if each criterion can be reformatted into a separate story.
The acceptance criteria becomes the middle of a user story narrative and then you can identify who would benefit from that story and what their goal would be. That creates a complete, smaller user story.
Timeline Analysis for Splitting Stories
The fourth wave splitting user stories is best for capabilities that involve user interaction. The approach is known as timeline analysis or use case analysis.
With this approach you identify the steps that a user must go through to complete a process associated with the user story. Each step in that process may then become its own user story.
This approach may allow you to validate and test with users as you deliver small pieces of functionality to ensure the solution meets their needs and make any needed adjustments.
Listen to the full episode for more examples on how to use these story splitting techniques.
Your Homework
Practice the four techniques for story splitting and sample user stories. Practicing these splitting techniques on made up stories allows you to try them out in a no risk environment. You also won’t be distracted by the real-world details within the context of your stories.
Links mentioned in this episode:
Chris Sims
Founder of Agile Learning Labs
Chris Sims is a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness. Chris is the founder of Agile Learning Labs and co-author of two best-selling scrum books: The Elements of Scrum and Scrum: a Breathtakingly Brief and Agile Introduction.
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
Trackbacks/Pingbacks