This hood is making an ineffective split of his face.

This hood is making an ineffective split of his face.

An anti-pattern is a typical response to a problem that is usually ineffective. There are numerous patterns for splitting user stories that are generally effective and there are an equal number that are generally ineffective. Splitting User Stories: When Things Go Wrong described some of the common anti-patterns such as waterfall splits, architectural splits, splitting with knowledge and keeping non-value remainders. Here are other equally problematic patterns for splitting user stories that I have observed since writing the original article:

  1. Vendor splits. Vendor splits are splits that are made based on work assignment or reporting structure. Organizations might use personnel from one company to design a solution, another company to code and another to test functionality. Teams and stories are constructed based on organization the team’s members report to rather than a holistic view of the functionality. I recently observed a project that had split stories between on project management and control  and technical activities.  The rational was that since the technical component of the project had been outsourced the work should be put in separate stories so that it would be easy to track work that was the vendors responsibility to complete. Scrumban or Kanban is often a better choice in these scenarios than other lean/Agile techniques.
  2. Generic personas splits. Splitting stories based on a generic persona or into stories where only a generic persona can be identified typically suggests that team members are unsure who really needs the functionality in the user story. Splitting stories without knowing who the story is trying to serve will make it difficult to hold the conversations needed to develop and deliver the value identified in the user story. Conversations are critical in the flesh out requirements and generating feedback in Agile projects.
  3. Too thin splits. While rare, occasionally teams get obsessed by splitting user stories in to thinner and thinner slices. While I have often said that smaller stories are generally better there comes a time when to split further is not worth the time it will take to make the split. Team that get overly obsessed with splitting user stories into thinner and thinner slices generally will spend more time in planning and less in delivering. Each user story should apply INVEST as a criteria to ensure good splits. In addition to using INVEST, each team should adopt a sizing guideline that maximizes the team’s productivity/velocity. Guidelines of this type are reflection of the capacity of the team to a greater extend and the capacity of the organization to a lesser extent.

Splitting stories well can deliver huge benefits to the team and to the organization. Benefits include increased productivity and velocity, improved quality and higher morale. Splitting user stories badly delivers none of the value we would expect from the process and may even cause teams, stakeholders and whole organizations to develop a negative impression of Agile.

Advertisements