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?
The answer may differ a bit from what you expect, since we use minimal marketable features, not stories. However we were writing stories in the first place.
ReplyDeleteIn our case a feature takes about a week to code (you can find more details here). If we wanted to split it to stories we'd need 2-3 stories on average, but we don't write user stories anymore. So in our team it would be similar to what you point: a couple of days per story in terms of coding.
However what I see very often is teams using significantly bigger stories. When I say "our feature could be split into a couple of stories" I often hear "oh, and our story could be split into a couple of features of your size." It basically means people often use stories which barely fit two-week sprints.
Personally I think features sized, say, 3-4 days are still small enough to let people easily decompose and analyze them on-the-fly. We don't write detailed design down before we start programming although decomposition for tasks like "create someNew.class" happen. It just comes naturally.
Thanks for the answer, Pawel. I would say some of the stories I have in mind are the same size as your MMFs -- it tok my team 2 to 6 days to code our stories (in a 2 week iteration). I guess it's all relative. If you have a team on the large size (a dozen programmers) then a story that will take 6 calendar days of effort for the whole team needs some careful decomposition before work commences. 3-4 days of work for 10 programmers may still need some decomposition in advance, just for the sake of coordination. It certainly depends on the team, the code base, the technology, and other factors, but at some point, smaller team and smaller stories could lend itself to decompose and analyze on the fly. But wouldn't you agree that some amount of decomposition has already been done in your head before you start?
ReplyDeleteYou touch the subject which is pretty hot in Kanban which is swarming: many team members focusing on the same piece of work to push it done-done stage faster. To be honest I'm not a fan of this approach. I prefer to split work into pieces small enough to have a single developer deal with it and big enough to avoid pushing few tasks a day for every team member.
ReplyDeleteSo yes, 3-4 days of work for whole 10-person team would be probably too big for me. But then again, it depends on all the specifics of project, team etc.
You're right about decomposition - we do this before we stick notes to the whiteboard. How could we end up with week-long tasks otherwise? Usually we do it collectively - we discuss which features we need to build to have some bigger functionality done (you can call it an epic). Sometimes, in simpler cases, product owner does it alone.