Cascade’s team is struggling, three sprints running they’ve been unable to build a potentially shippable product. The developer’s complain there isn’t enough time in a two week sprint to get their work done. They want three week sprints. The testers complain that the only get something to test in the last three days of sprint and even then its usually too buggy to work with. Cascade calls her old friend John who seems to be having more success with Scrum.
John does some digging and finds the following data about (expressed in Story Points). The team had committed to 41 points of Stories sized: 5, 8, 13, 5, 8, 2
NB The in several cases a single story is both in (Analysis and Development) or (Development and Test) at the same time.
From here John chats with Cascade to find out how the work flowed. She explains that on Tuesday the four developers grabbed the first three stories (5, 8, 13) and just disappeared for a few days. During Friday’s Daily Scrum one of them said that he realized the ‘2’ was closely related to something he was already working on and he grabbed it too. Towards the end of the sprint the developers started throwing code over the wall to the testers saying: “they will figure it out”. In addition when the testers find problems they insist on logging all the details in the bug tracking system instead of just talking to the developers first. In addition when Testers find a bug the developers often put up a fight rather than collaborate to fix it.
There are a number of possible causes that lead to this state:
- Large stories – lead to everything getting finished later
- Individual work – leads to a lot of work being started and little being finished. Notice on Wednesday four developers started three stories. That seems to suggest that there is very little collaboration going on.
- With so much Work in Progress, everything is started and nothing is finished
- The Developer/Tester divide is alive and well
- Use of the bug tracking system in sprint is further enlarging the Developer/Tester divide.
John suggests to Cascade that they go out for coffee (a ScrumMaster’s secret weapon). He explains that it seems her team has a very serious case of ScrummerFall or Waterfall practiced inside Scrum. He goes onto show that by starting most the Sprint’s work at the start they’re very unlikely to get everything done. Instead what they’ve done guaranteed the first bottleneck. He suggests the first thing they do is learn to start slicing their stories into smaller more digestible chunks. Cascade is confused and wonders about the loss of efficiency. John tries to explain that a focus on efficiency often leads to slower overall throughput but this doesn’t make sense to her.
In the end John proposes she gather together the team and they play the penny game (Ed: the version I do just times the overall process and not the individual workers). After playing the game and running the debrief they make the rather surprising discovery that the smaller they slice things the faster value gets to the customer and better their overall throughput. Cascade sets up meeting to start splitting some of their upcoming stories.
In addition to Splitting Stories the team could:
- Pair Programming – to get each individual story done sooner
- Test Partially Complete Work – instead of waiting until all the work is complete
- Skip the Bug Tracking System – in Sprint most bugs can be handled with a quick conversation instead of the time consuming use of a tracking system.
- Focus on the Early Discovery of Bugs
- Discover Acceptance Test Driven Development (ATDD) and Specification By Example so that they work collaboratively to discover the acceptance criteria. In addition they can write the tests before they write the code.
Inspired by frequent questions on the subject of “What percentage of time should I allocate for Analysis, Development and Test in a Sprint”.
Part of an ongoing series called Scrum Master Tales. The series covers ScrumMaster John and his team as they develop an online bookstore.