Complicated user story!

Complicated user story!

A user story (See User Stories, October 28, 2013) is a brief, simple requirement statement from the users perspective. The classic format of a user story is:

“As a <persona>, I want to <goal> so that <benefit>.”

When initially constructed, a user story can represent a concept that the team can’t wrap their mind around and can’t finish in an individual iteration. Therefore the user story needs to be broken down into smaller chunks. Large user stories have three main side problems that can be addressed by breaking them down.

  1. They’re harder to understand.  Large stories generally represent multiple, related business concepts. An example of large story might be, “As a business man, I need to book a trip from Cleveland to Philadelphia so that I can attend a meeting.” Anyone that has booked a trip knows that are a number of smaller stories embedded in this larger story.  Booking the trip may well include an initial conveyance (plane, train or automobile), lodging and potentially rental car.  Until the larger story is broken down, it is difficult to determine if all of the parts have been identified.  It is also more difficult to determine how long it will take to complete the story, making it difficult to know if you have taken on too much work.
  2. They take longer to elicit feedback.  Agile techniques elicit feedback as work is being done. I have always found it easier to solicit feedback when I have something to show and acceptance criteria to compare against.  Acceptance criteria are typically constructed so that we can know when the overall story is complete.  When we are dealing with larger stories, we need to wait longer to get enough work done to use acceptance criteria as a comparison tool. For example, if I broke out conveyance to the meeting from the overall story, I would be able to get feedback on potential plane or train tickets (I am not driving) earlier than if I had to plan the entire trip.  Even if the only feedback point is at the demonstration where the completed story is reviewed by a wider set of stakeholders, a large story may fail to complete therefore miss getting formal feedback for one or more sprint.  Feedback is important to avoid rework.
  3. They can clog the flow of work.  The one thing that is always true in software development is that we never foresee all eventualities (popularly known as “stuff happens”). Generally when a team is working on a large story a substantial portion of the team is involved in getting all of the tasks done.  When something goes wrong or new tasks are discovered, it is highly probable that other planned work will be delayed.  The large story will clog the process.  Using our trip example, if I need to price Amtrak (train) and United Airlines (plane) and found out that United did not fly to Philadelphia, I would have to stop and research other flight options.  The new activity may well cause me to postpone other tasks I had planned for the day.  Breaking stories down into smaller pieces makes it less likely they will be stuck for long and when they are stuck it will be less likely that the whole team is stuck working on the problem. Value can continue to be delivered.

Smaller stories are easier to understand, estimate and implement. When the team understands a story they will be better able to deliver the value inherent in the user story.  The ability to understand is critical to reducing the possibility of surprises when they are developing the solution.  Surprises, when they do happen, will have less of an impact on the team if the stories are small enough so the whole team is not stuck.  Breaking down larger stories increases the through put and therefore increases the amount of value delivered.

The remainder of the week will be used to explore how to split stories.