by on September 9, 2011 in Scrum, ScrumMaster Tales

ScrumMaster Tales – the Story of an Incomplete Sprint

puzzleLast time we met John (ScrumMaster) and the team, they had just discovered that their backlog had many large stories and no-estimates. The team delayed the start of their first sprint, did some Product Backlog Grooming. When we meet them again their first sprint in is in progress.

Story

Coming out of the planning meeting the team committed to five stories totalling 42 Story Points. Their overall Sprint Goal get the customer’s book home:

  • As a book buyer I want to add my book to my shopping cart so that I can purchase it – Story Points: 13
  • As a book buyer I want to tell Amazon where I want my book shipped to so I can get it – Story Points: 8
  • As a book buyer I want to see the price for my books with shipping and tax so I can see whether I’m ok with the price – Story Points: 3
  • As a book buyer I want to choose my payment type (MasterCard, Visa, Amex or Paypal) so that I can pay for my book(s) – Story Points: 3
  • As a book buyer I want to pay for my book(s) so I can get it home – Story Points: 13
  • As a book buyer I want a confirmation message so I can see that the purchase was successful – Story Points: 2

The team (7 team members including John) started work on the first four stories right away (27 Story Points in total). Tonia the team’s on QA specialist spent the first few days with Brad (the BA) clarifying the acceptance criteria for the stories and designing her manual test cases. She also worked with a couple of developers to clarify the details of the stories. By Monday (Day 5 of the Sprint) she had completed all of this work and was hungry for an application to test. In fact she was wondering why she hadn’t seen it as promised on Friday. Lacking an application to test she found other things to do outside the team. It wasn’t until Wednesday (Day 7) that she finally had the first story (“add my book to my shopping cart”) ready for test. Tonia scrambled but it was a big story and took much of the day just to get the environment ready to test. By day’s end she had found a dozen issues and shared them with Ian. “Add my book to my shopping cart” was clearly not ready yet. In the meantime other stories were piling up in front of Tonia and she was unable to keep up with the testing. At the end of the Sprint Sue only accepted two stories as complete “see the price for my books with shipping and tax” and “choose my payment type” for a total of 5 Story Points. Everything else was incomplete.

In the retrospective the team identified a number of things that contributed to the problem:

  • They over-committed
  • They took on large stories with splitting them down more
  • They had too much work in progress

For the next sprint they identified several improvements they could make:

  • Always split stories of size 13 or larger
  • Never have more 3 stories in progress at once (that forces people to collaborate on Stories)
  • Handoff incomplete Stories for early testing. Early feedback on partially complete work will help save team members going down many dead ends.
  • When working on larger stories 5 and 8 swarm them

Analysis

Nearly every time I’ve seen a team take on a story of 13 points or more the team doesn’t succeed in completing it in that Sprint. Usually because stories of that size have alot of hidden complexity and surprises.

I’ve also noticed that limiting the number of stories in progress to less than half the team size i.e.

Team Size Limit on # of Stories in Progress
5 2
6 3
7 3
8 4
9 4

Helps ensure that work is completed before new work is started. Kanban folk achieve the same effect by setting up their Kanban board and setting WIP limits.

Finally when a team is new and is having trouble seeing the effects I create a simple table on a white board:

Story Points by Day

M T W T F M T W T F
Development 27 27 27 27 27 27 27 14 9 9
QA 0 0 0 0 0 0 0 13 18 9

N.B. The QA/Development split isn’t meant to encourage this to happen its just a reflection of what most teams deal with when they first start.

Combined with a Sprint Burndown (in Story Points) it help the team spot problems as they start to happen and diagnose them in the Retrospective.

What tools do you use to help teams see these problems?

Be Sociable, Share!

Related posts:

  1. Scrum Master Tales–The Story of the Changing Needs
  2. ScrumMaster Tales – Story Splitting Fun
  3. ScrumMaster Tales–Stop Digging New Holes
  4. Scrum Master Tales – The Story of Production Support
  5. More Notes on Story Splitting

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.


  • alfred almendra

    To bite off more than one can chew.
    Always need to “loose” one sprint to figure it out.
    Thank you for the points per day table idea.

  • Mark Levison

    Alfred – its interesting I invented the table because there were teams who didn’t see the problems I saw on their Story Board or Burndown (of CFD for that matter). Doing this and waiting a few sprints helped make clear the correlation between large chunks of Work In Progress and incomplete work.

    Cheers
    Mark

  • Uriah Blatherwick

    By observation, these problems are incredibly common. It would almost be nice if there was some guidance like this included in the core practices for scrum etc. As far as I know, there isn’t anything in a the typical CSM course that talks about swarming or stored in progress. That might be an outcome of the “self directed teams” principle, but really seems to be something most teams stumble on pretty quickly. I like your solutions a lot and plan to use them when starting companies on the Agile path in the future. Thanks!

  • Mark Levison

    Uriah – thanks for the compliment. Like many other CST’s I do my best to cover a little bit of this in my class. However 2 days is never enough time and something always gets dropped. If I covered this well maybe I would have to drop Agile Engineering techniques (close to my heart). Even the course were 5 days long there would still be stuff I missed. This series of posts is my attempt to make up for these failings.

    Cheers
    Mark

  • http://web.me.com/seabreezes1 Karen

    Yes, this is really common. It’s an example of “cargo cult” implementation, i.e. using the trappings of Scrum without understanding the underpinnings. Not only does the team need to limit the work in progress, they need to “pull testing forward” by designing automated testing and pair programming, etc.

  • Mark Levison

    Thanks Karen – I’ve not mentioned pull, automated testing, TDD or anything else like it yet because I’m trying to make the stories as close to life as I can. Most teams take a while to mature to the stage where they can take on test automation etc.

    Cheers
    Mark

  • Tony G

    The word that jumped off the page at me is “handoff!” To me that is a red flag that there is mini-Waterfall occurring within a sprint. Also the fact that Tonia had things “piling up” in front of her, hints at a bottleneck. I’m a little concerned that nothing was mentioned about developers helping Tonia with testing. We’ve dealt with this on a small scale, but when I, as Scrum Master hear these types of statements in stand-up meetings, I start asking questions such as “What can the team, as a whole, do to help move these stories to ‘done’?” and “Tonia says she is backed up, is there anyone that can help her with testing?” Then during our retrospective we talk about things we can do to change this tendency toward mini-Waterfall.

  • Mark Levison

    Thanks Tony – I’m with you the handoffs are definitely a problem and yes clearly the team has discovered Scrummerfall. I like your approach to solving these problems. Again we will see how they deal with this problem in a later sprint. Helping teams help themselves is slow.

    Cheers
    Mark

  • Tony G

    Thanks, Mark. Just a quick note, we do 1 week sprints, which really helps reduce lag time when dealing with these types of problems. So dealing with the problem in a later sprint is only waiting a week :)

  • http://www.pmhut.com PM Hut

    Hi Mark,

    I would like to republish this article on PM Hut ( http://www.pmhut.com ) under the Scrum category. Would that be OK with you? If yes, then please either email me or contact me through the “Contact Us” form on the PM Hut website.

  • http://www.softwareresults.us/ Dave Moran

    Mark,

    Interesting post. I agree that teams don’t always see problems emerging in their story/task board. Limiting WIP and your table will help them visualize the situation. As Tony points out, bottlenecks were clearly emerging. I recently blogged about how to help teams using another technique.

    http://www.softwareresults.us/2011/10/elevator-story-guiding-behavior-changes.html

    I’d be interested in your take.

  • Mark Levison

    I wrote a longer reply on Dave’s blog. His idea is well thought out and will help. Key to any approach like this:
    - Keep task sizes small (< 1 day/per task)
    - Make the problem visible when it happens.
    - Ask people to help by swarming

    Cheers
    Mark