Scalability is probably a separate story from being human.

Scalability is probably a separate story from being human.

Splitting stories can have a significant impact the team’s delivery capacity. Splitting stories helps a team work at a greater velocity.  Splitting stories can also lead to higher team morale, as teams deliver more, more successfully.  Finally splitting stories deceases the potential of waiting and stuck stories, which yields increased productivity. Tools that make splitting stories easier therefore are valuable.  Patterns are a simple tool for splitting stories.  Patterns help teams and team members split stories by providing a framework to quickly make decisions based on the information at hand (for more on this, read my essays on cognitive bias).  Yesterday we explored four patterns for splitting users stories primarily based on functional flow.  Patterns based on other criteria include:

  • Splitting Non-functional Requirements: Requirements such as scale and reliability can add substantially to the effort required to complete a story.  Splitting the functional from the non-functional can be used to create two smaller stories.  For example, the story “As an employee I need to be able enter my time 24/7 so that I can work in any time zone” could be split into the two stories, data entry and availability.
  • One/Many:  This is a trick I learned when learning assembler (I recommend this activity to everyone – misery loves company).  The trick is to get the base or single transaction to work then move on to handing the many.  Using our time accounting example: the user story may call for adding multiple lines to an employee’s time card.  In this case you can split the story into two; add one line and add many lines.
  • Transient/Persistent data: Transient data exists only while it being used, and is usually stored in local random access memory (RAM). While persistent data is stored in a file or database, and is therefore available to others. Creating persistent data typically requires more thought and work (note good re-use libraries can reduce the overhead of developing persistence data).  Again revisiting our time accounting system, if a story were to require that the user could leave the system after keying part of his or her time into the system and then to enter later without loss of data, persistence is inferred.  A possible split would be to get the transaction right then deal with persistence as a separate story.
  • And/Or: Conjunctions, of any sort, are fairly obvious markers that you can naturally split a story.  Consider splitting any story that includes an “and” or an “or.”  Contractors need to enter their time, review their time and approve their time so they can get paid.  This is a nice epic that could be at least three stories.

Patterns help teams make decisions quickly, much like the way recognizing patterns helped early humans stay alive by recognizing situations where they would be likely to run into predators. Splitting stories based on patterns is not a science, but a tool that, wielded by a knowledgeable team, can be effective.  As you are applying patterns remember the rule, a story must represent potentially implementable functionality, and the concepts embedded in INVEST to stay away from story splitting nightmares (more on that here!)

Advertisements