Make sure your story is the right size

Make sure your story is the right size

Smaller user stories have significant benefits. So, why wouldn’t we break down all stories?  The law of diminishing returns is alive and well in the realm of story splitting. Generally, splitting stories is not a simple process, and therefore requires time and effort. At some point the value from splitting a story falls below cost (both the effort and the opportunity cost of not doing something else). Size and testability are the leading filters for right-sizing stories.

Stories must be small enough to be completed during a single iteration if we are going to deliver potentially releasable software at the end of each sprint. The story should be sized so that it does not require the whole team to complete. As described in Splitting User Stories: Why, small stories increase the flow of work through the team and when things go wrong, a single story won’t block the entire sprint. What is the right size for a story?  It is my observation that all teams develop a norm that they find useful.  As a rule of thumb I suggest that each story should be split until they can be completed in 2 to 3 days and require no more than 1/3 of the team at any one time.

Stories need to be testable within the sprint’s time box.  A reflection of the time it will take to develop and test any story is the number of acceptance criteria needed to prove a story is complete. A rule of thumb I typically suggest is that a story that requires more than 5 to 7 acceptance criteria should be split.  A corollary, if groups of acceptance criteria are unrelated then the story should be split. For example, I recently reviewed a story whose acceptance criteria required that employees were able to review their time accounting data and that supervisors were able to review the time that had been entered.  We split the story into two stories, the first for employee time review and the other story for the supervisor’s review.

As I am splitting stories, I use Bill Wake’s acronym INVEST as a framework when deciding if the split I have made makes sense.  INVEST stands for:

  • Independent: they stand alone
  • Negotiable: they are a conversation
  • Valuable: they deliver a benefit
  • Estimatable: the team can determine how long it will take to complete the story
  • Small: or sizeable, and
  • Testable: the story can be proved

When a story is split, apply the implicit questions embedded in INVEST to make sure the result still makes sense.  Can the stories stand alone?  Are they still valuable (if not, can part be jettisoned)? Are the resulting parts small enough to be estimated and completed in a sprint?  Finally, can we prove that we have solved the business problem that each story represents? If answer to all of INVEST questions are positive, we are done splitting and we can move on to the next story or, better yet, start developing.