Too many things going on will lead to less attention to anyone subject.

Too many things going on will lead to less attention to anyone subject.

Splitting user stories is an important tool to help teams in a number ways ranging from improving the flow of stories through the development process, to improving the teams understanding of what is required to deliver the story. In almost every case, smaller is better.   We have identified a number techniques for splitting user stories and a framework for evaluating those splits. Additional splitting techniques include:

  1. And/Or Removal: User stories that include “and” or “or” typically reflects compound thoughts. This is an indication that the story is an epic, which will too large to be complete in a single sprint. Split the stories to eliminate instances of “and” and “or“. An example of a story with an “and / or” problem is: As a project manager I want to be able to review and approve time and expenses logged to my projects to ensure accurate reporting and billing. Stories could be constructed separately for reviewing time accounting, approving time accounting, reviewing expenses and approving expenses. Simplicity reduces the potential for confusion.
  2. Simple/Complex: Complexity makes a story harder to complete and therefore the story will take longer to deliver compared to a similarly-sized, simple story. Splitting can be used to isolate functionality that is more or less complex. Splitting based on complexity provides product owners the option of deciding on whether a strategy of doing the simple stories first. This approach could provide teams with insights that reduce the complexity of later stories.
  3. Splitting Non-functional Requirements: Many user stories combine function and non-functional components. For example the story “As a home brewer, I want a conversion calculator that returns results in 40 point type display so that I can determine the alcohol level in the beer.” The story could be split to address the functional side of the story (conversion results) from the non-functional component (size of display). Splitting the story lets team to deliver the calculation before having to address how it is displayed.

These three patterns for splitting user stories (in addition to those noted in previous articles including workflow, business rules, data variations, elementary processes or syntheses of patterns) are just tools for teams. Teams split stories to help them understand what they are committing to deliver, to reduce the complexity of large stories (or at the very least to isolate the hard parts) and so they can enhance their ability to consistently deliver value. Splitting stories increases productivity and quality and reduces the amount of time the team spends scratching their collective heads trying to figure out what they will deliver and how they will deliver.

Advertisements