It’s a game of two halves

Does development process for the stories you build in the first half of the sprint flow nicely, do you have few defects? How about the second half of the sprint? Do you miss things, are there more defects?

The team I am currently working for rocks our current Scrum practices are well embedded and understood. However a pattern has emerged as our velocity increased, we miss key elements / forget design details of the lower priority stories and thus they have more defects than those at the start of the sprint.

So for this sprint I asked the team if we could try a new way to plan our sprints, they agreed and this is what we decided to do.

  • Use our velocity as we normally would to help us understand how many stories to initially take in to planning
  • We then make an arbitrary split on half the stories rough velocity for half the sprint
  • Then it’s sprint planning for the first half of the stories (detailed design, how we test, proving the acceptance criteria etc)
  • When we get close to finishing these stories we do the same for the next batch

So far this has worked well for us and the level of detail has gone up and the number of defects has dropped again, so this looks like a practice that we might follow again, the retrospective will bring out any further tweaks.

I would be interested to see if anyone else has tried this or has spotted this pattern.

Mike Lowery
3 Comments
  • This would seem like a fix rather than focusing on the problem, which would appear to be the team delivering consistant quality.

    Has the teams velocity really increased if they are missing key elements.

    The team could try being less ambitious in what they are hoping to deliver and make a more detailed acceptance criteria.

    August 8, 2012 at 1:52 am
  • Stephen
    Reply

    We saw a similar problem and have moved to two week long sprints – which sounds roughly like what you’re doing – you call it re-planning, I call it planning the next (shorter) sprint. I do not intend to do this with the team for too long though as the pressure is increased and the stories and ‘meaty-ness’ of the work goes down, we are also less likely to be able to deliver “potentially shippable product” at the end of a two week sprint.

    August 8, 2012 at 7:20 am

Post a Comment