by on July 18, 2012 in ScrumMaster Tales, User Stories

ScrumMaster Tales – Story Splitting Fun

Split-ApplePicking up from: Learning How to Estimate

The team are still in the Backlog Grooming/Refinement session. They’ve estimated a heap of stories and spotted several that need better Acceptance Criteria. However, there are several stories that Product Owner Sue would like to have worked on which are too large to commit to in a single Sprint. While they could estimate the Stories as they are this seems like a waste of time. They’re better off getting out the scalpel and splitting the stories into smaller parts.

First a quick reminder from – Why Split User Stories:

 

Why not just give the team large stories that span iterations. Why slice those stories into smaller parts? A number of reasons:

  • Small stories provide focus and a short horizon for the team. It’s easier to get lost in the details with a larger story.
  • When you still have development to test handoffs (i.e. before you start doing ATDD (Acceptance Test Driven Development), smaller stories enable more frequent handoffs and allow testers to work on smaller chunks of code.
  • Small stories give you the flexibility to reconfigure and adapt to new discoveries or changes. Perhaps the PO discovers that an existing story is now irrelevant; or while coding you discover a surprise. Small stories make it easier to adapt.
  • Small stories provide more feedback opportunities at all levels of the system and more opportunities for personal satisfaction; think of the small dopamine rush that happens every time you complete something!
  • Large stories increase the risk that your team will deliver nothing at the end of the iteration.
  • Your team has a capacity like a drain pipe and just like a pipe the larger the object you try to push through it the more likely it is that blockages and bottlenecks will occur. Perhaps one person who is tied up in the large story may also be the only person who can complete a key piece of another story.

Story #1: “As a first time book buyer I want to find the perfect mystery novel so I can while away the time on my next plane flight”. Size: 100

Brad makes the quip that this appears to be the core of the website in a single story. (Mark L. – Early on in our story writing career this often happens. We write large chunks of our product in a single User Story. Rather than trying to avoid it, just get it out and then split it.)

After they finish laughing the team get involved in discussion around the parts of the story. In the first round the discussion focuses on the database (Pythia 22x); how difficult it will be to get right; what the right format for the staff reviews would be, and how to get a book home in time (FedEx vs. UPS vs. Purolater). They crank out some new stories:

  • As a first time book buyer I want to find the perfect mystery novel quickly with an Pythia 22x database
  • As a first time book buyer I want to have my perfect mystery novel shipped home via FedEx so I get it in time for my next flight
  • As a first time book buyer I want to see the star rating on a review before I read it so I can see whether the book is worth reading
  • As a first time book buyer I want to select my book and place it in the shopping cart so I can buy it
  • ….

Analysis

Most of these revised stories have in common a focus on technology vs. solving the need of the end user. A User Story is “a single sentence that describes a small piece of valuable functionality from the point of view of the end user”. Real end user’s don’t care about our database technology nor our shopping carts. They just want working software. By writing User Stories from their point of view we delay making technical decisions until its useful from the Point of View of the application.

Story

Scrum Master John reminds the team to place the focus on the value for the end user; in this case, the “first time book buyer” and not the technology.

In their next attempt the team break the stories down:

  • As a first time book buyer I want to find the perfect mystery novel by reading staff reviews so I won’t waste my money reading bad books
  • As a staff member I want to enter book reviews so I can delight book buyers
  • As a first time book buyer I want to see only books that get five star reviews so I don’t waste my time reading reviews about weaker books
  • As a first time book buyer I want to select a single book for purchase so that I can read it (Mark L. – the team have elegantly avoided solving the whole shopping cart problem for the moment by handling just a single book. Clearly they will later need to handle multiple books but if they can’t get one book home they can’t get more home).
  • As a first time book buyer I want to ship my book home within two days so that I can get it before my next flight

The team estimate the revised stories, this time most of them are reasonably small except: “As a staff member I want to enter book reviews so I can delight book buyers” which is estimated at size 20 (they started off at 40). Sue says at first it would be fine to support only plain text and a star rating. The reviews wouldn’t have to be updated once written. She’s willing to offer a lot. Nonetheless the team say it’s a large problem to enter text, save it in the database and display it on the book page. Sue asks the team, “Can we display the reviews first and solve the problem of entering them in the system later?” “Ludicrous,” says Martin, “What’s up with that? How can we display reviews before we even have the text? Even if we could we need to get the database right.”

Sue explains that she needs to talk to the Product Steering committee in the next few weeks. Her goal is to have a Minimum Viable Product (i.e. a down payment on the vision) in place. To get continued funding for the product the team needs to be able to demonstrate the basic flow for the “first time book buyer”, i.e. Read a review –> Buy the book –> Ship the book home. While the reviews need to exist to demonstrate the product we can live with reviews that were entered directly into the database. Sue goes on, “For the next couple of Sprints I could even live with fake reviews if that helps. Its about being able to demonstrate the basic experience whilst not having the back end working right now.”

If the product gets continued funding from the steering committee then they can decide how to flesh out the support for staff reviews. After some more discussion the team come to see Sue’s point of view. They write a new story: “As a first time book buyer I want to read staff reviews that are displayed on the book’s page so that I can buy the perfect mystery novel.” After a couple of rounds of Planning Poker the team agree to estimate the story at 5 points.

Analysis

In this case Sue was trying to get the team to consider “Independent” from INVEST (Bill Wake’s criteria for good User Stories): “Dependencies between stories limit the flexibility of both the Product Owner and development team. The Product Owner should be able to ask for stories in whatever order they make sense.” When the team said that they needed to write the staff side of the review system before displaying any reviews they were taking prioritization over from the Product Owner.

N.B. If the dependency is just around sizing/effort then it’s OK for the team to say, “This type of story requires a templating engine; the first one will be sized 13, all subsequent stories will be sized 2.”

End Story

There are several dozen interesting ways to split stories; some more ideas and examples are found in:

http://www.richardlawrence.info/2009/10/28/patterns-for-splitting-user-stories/
http://agilepainrelief.com/notesfromatooluser/2010/12/more-notes-on-story-splitting.html
http://www.agileforall.com/2009/12/10/new-to-agile-learn-how-to-split-stories/
http://lassekoskela.com/thoughts/7/ways-to-split-user-stories/
http://xp123.com/articles/twenty-ways-to-split-stories/
http://blogs.collab.net/agile/2012/06/20/15-ways-to-split-an-epic-a-team-exercise/
http://blog.gdinwiddie.com/2011/05/01/splitting-user-stories/

What problems have you had splitting stories? How did you split the stories in the end? What would you do differently today?

Be Sociable, Share!

Related posts:

  1. ScrumMaster Tales – the Story of an Incomplete Sprint
  2. Scrum Master Tales–The Story of the Changing Needs
  3. More Notes on Story Splitting
  4. Scrum Master Tales – The Story of Production Support
  5. ScrumMaster Tales – The Team Gets Bottlenecked

Certified ScrumMaster TrainingIf you enjoyed this post take a look at Certified ScrumMaster Training. We currently have courses scheduled in Ottawa, Montreal, Toronto and Edmonton.


  • http://www.facebook.com/lizheliu Lizhe Liu

    A good article that shows examples for the concept of
    “Minimum Viable Product” and user story independence, and the rationale behind!

    I think the following statement may need to be slightly
    rephrased though:

    “When the team said that they needed to write the staff side
    of the review system before displaying any reviews they were taking prioritization over from the Product Owner.”

    Instead of saying “they were taking prioritization over from
    the Product Owner”, I think it’s actually valid and healthy for the team to provide
    their inputs from development/technical perspective. Business value is of course the number one criterion for
    prioritisation, but other criteria such as technical risks, implementation
    difficulty, or relationship to other requirements are also important, and PO
    may not be fully aware of them until the team present their view based on expertise or experience. While ultimately it’s the PO’s responsibility to
    decide the priorities, it’s more of a collaborative effort than someone is
    taking over prioritization from another.
     

  • Dov TSAL SELA

    Great post!

    My take-away from the story is the all important lesson that developers should understand the PO’s and the customer’s REAL needs, once this is achieved the rest is much easier, and there is less risk of delivering the wrong thing or at the wrong priority.

    So in your story, even if the total estimation for the whole “staff should be able to review” was shorter, dev could point out a mockup solution and suggest taking other issues that are Steering-commitee related.

    As in Rugby-scrum, no reason why dev should not attack the real issue with the PO, if they are up to it.

  • Pingback: ScrumMaster Tales – Waiting Too Long to Create Acceptance Criteria | All About Agile

  • Pingback: User stories should be implementation free | On Product Management