Skip to main content

How to Teach a Scrum Team to Split Stories

December 7, 2017

How to Teach a Scrum Team to Split Stories
 

Many Scrum Teams have difficulties with splitting user stories. Often I hear people saying: "It's absolutely impossible to split this product backlog item.” In order to solve this issue, I recommend organizing a workshop on story splitting for the entire Scrum Team.

This article describes how to facilitate such a workshop. Many Scrum Teams prefer using a format of User Story when working with Product Backlog Items (PBI), thus, I will be using “stories” and “Product Backlog Items” interchangeably.

Discuss the importance of splitting the stories


Before the meeting, make sure you get the Product Owner aboard. First, ask everyone why it is important to learn how to split big stories. Ask the team to form small groups and let them discuss this question for a couple of minutes. Then, start an open discussion and write down the answers on a flipchart.

Learn and teach the principles of story splitting

Count off the whole group in twos . Give participants with odd numbers printed patterns for splitting user stories, and those with even numbers give a cheat sheet of examples of each pattern. Ask everyone read the documents thoroughly over 10 minutes.

The most effective way of learning is teaching others. When ten minutes are up, ask the even numbers to pair up with the odd ones. Give another ten minutes for teaching the material they have just studied with each other (five minutes in one direction and five minutes in the opposite direction).

Move from one pair to another and answer their questions if needed. I recommend you avoid an open discussion as much as possible. It is better to answer the same question several times in small groups than to get stuck in an open discussion for a long time and drop the group dynamics. It is the main principle of facilitation, which I adhere to; working in small groups over an open discussion.

Split one of your big stories

I always ask the Product Owner to bring a story(epic actually) that he would like to split in advance.

Ask how much time the team will need from the Product Owner to answer all the clarifying questions about the story he has chosen. Depending on the answer, start a timer and facilitate an open discussion. Help the discussion to stay focused. The developers often delve into less important themes and digress. You need to keep them focused.

After the Product Owner has clarified all the details, form small groups of no more than four. Make sure every group has a domain expert or a business analyst in it. Give them twenty minutes, provide the necessary materials (flip charts, boards, markers), and ask to split the story into at least ten smaller ones. Move from one group to another, answer any questions that arise and provide support in every way possible.

Put all the results on one list

Return to the open discussion, and ask each group to present the results of their work. After each presentation, ask these questions: What's the most interesting thing that you have noticed? What new stories have you discovered from this group?

After each group has presented their splitting options, make the final list with the whole group. If you followed the algorithm, you could come with a list of 10-20 stories. These stories have not been described in sufficient detail yet. You will have to deal with this at the next PBR activity.

Key thoughts of the article

  • Story splitting is an important skill that helps Scrum Team to deliver higher business value items faster.

  • One workshop (2-3 hours long) is enough for the Scrum Team to learn how to split stories.

  • The key to effective facilitation is working in small groups.

  • The most effective way of learning is teaching someone, then practicing it. Print out splitting patterns and let people teach each other. Then apply it to a big user story.

Scrum ON!


 


What did you think about this post?