Pages

May 18, 2010

You break your stories down /when/ ?




http://www.flickr.com/photos/pointshoot/ / CC BY 2.0

I've had a revelation. The other day I was talking to Mike Cottmeyer about Scrum and how I don't like the idea of tasking out and estimating all stories at the start of the sprint and then signing up for tasks, all before committing to the Sprint backlog.

When I first started doing XP in early 2000 we tried that and it was painful. Painfully long. Painfully tedious. And it felt painfully like Big Design Up Front even though it was for one or two weeks worth of work.

One team I was with for a handful of years broke our stories down into small 1 to 6 hour sized tasks and we pair programmed (up to 10 of us) on a limited number of stories (preferably 2, normally 3-4, but it could get up to 6-8 near the end of the iteration if something got blocked and if we had lots of abnormally small stories in the iteration). One person with an optional pair would design a story just in time and then walk the team through the details and proposed tasks and get their input. All the tasks were written on the whiteboard and this drove all development. Tasks were small and explicit:

  • extract foo.class from fred.class
  • extract bar#makeGenerous from #makeMagnanimous
  •  introduce strategy pattern to someOther.class
  • create someNew.class
  • domain/persistance/patch for someNew.class
  • write the acceptance test
  • etc.

That design work could take up to a day or two to do for some of our stories. There is no way it would make sense to design all of our stories at the start of each iteration before committing to the iteration. That's how we did it using XP.

Tasks in Scrum, however, seem to be around 8 to 16 hours long, according to what I'm reading. And that was the new insight I gained. Some teams do things differently. (I'm slow sometimes, but I usually catch on.) With tasks that size, you could easily identify the tasks and estimate them before committing to the sprint. Further, teams that don't pair-program or that have too much specialization or too much code ownership need to break their tasks down by specialty and assign each task to the person that can implement it. Such teams would need to do this step before committing to the sprint.

I was blinded by my experiences being so similar to one another for such a long period of time. Help me see. How big are your story's tasks and how and when do you estimate them?