This is the third in my series on splitting larger user stories into smaller user stories. If you are just joining us, go back and read part one and part two. Don’t worry, I’ll wait right here for you.

Like the first story splitting technique (Conjunctions and Connectors technique), the second technique (the Generic Words approach) works by parsing the text of the user story. This time, instead of looking for connector words, we are looking for generic words. “What’s a generic word?” you ask. Any noun that isn’t a proper noun is generic, as are many verbs, adjectives, and adverbs. What we are looking for is a generic or general term in the story which could be replaced by several more specific terms to create a number of smaller stories.
Read the full article…

As I described last week, splitting large user stories into smaller user stories has many benefits for the scrum team and the business. We also agreed that before we try to split a user story, we want to write it in the traditional format:

As a <type of stakeholder>,
I want <the deliverable>,
so that, <some value is created>.

Read the full article…

A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate, and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.

When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so we can adjust the product plan, to better build the product our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality being developed.
Read the full article…