malvasia bianca

At the Sun Engineering Conference a couple of months ago, I went to a workshop by Ron Jeffries on agile planning. That inspired me to try out the (XP) technique that he was proposing: the idea is to plan all work in terms of “stories” that you estimate will take between 1 and 3 “points” each (where “points” is some linear measure of duration). You do your work in iterations; each iteration, you pick a bunch of stories, and try to implement them. The theory is that, as you get practice with this, two things happen:

• Your estimates get pretty accurate: most of the time, if you say a story will take 2 points, it actually does, and overestimates are as common as underestimates. (In contrast to traditional software estimates, where underestimates are much more common than accurate estimates, and overestimation is inconceivable.)
• Your “velocity”, the number of points that your team finishes in an iteration, settles on a value.

If you combine these two, then you’ll be able to accurately estimate how long it will take your team to carry out a project: break it up into stories, estimate the stories, add up the points, divide by your velocity, and there you have it! And if an unexpected surprise happens, or if externally-set priorities change, you can easily figure out the effect of throwing away no-longer-necessary stories or adding new ones.

So I decided to have my team try it out. We wrote down a bunch of stories on cards, and tried to estimate them. Our iterations are one week long; we decided a point would be an “ideal programmer-day” (i.e. the amount of work you’d get done in a day if you didn’t get interrupted at all); we figured that people would get no more than 3 ideal days worth of work done in a week.

After running our plan by Ron, it turned out that there was one main thing we were doing wrong: our cards were (frequently) focused on technical tasks instead of user stories. The latter is desirable so that the customer can easily direct and respond to what you’re doing; it also helps reduce the frequency of situations where priorities change and you’ve got a lot of stuff half-done that, while looking like natural steps from a technical point of view, has no business value whatsoever. In particular, we had too many “hygiene” tasks scheduled: tasks that were solely for the sake of cleaning up our (flawed but improving) code base, to improve its future reliability and maintainability.

If we were a pure XP team, we’d have somebody playing the “Customer” role (hopefully an actual customer!), and then we’d handle things differently. We’re not yet a pure XP team; given the lack of a Customer, I didn’t think this flaw was urgent to deal with right now: the story cards should have enough other benefits to be worthwhile.

We’ve been doing this for about two months; here’s the progress report.

• Our velocity has stabilized nicely: my group does 11 points of work per week.
• Our estimates aren’t always on target, but they’re not too bad, and are probably getting better.
• Given the above, I suspect that we could reasonably successfully estimate how long it will take us to accomplish larger projects (by breaking them up into small ones). We haven’t tried to do so, however.
• We’re getting better at breaking up projects into small steps. This helps me feel more in control; I’m not sure how much of this is a psychological benefit versus a practical benefit, but I like it.
• We’re doing a somewhat better job of not having people embedded in fixed roles. It’s still largely the case that we have an idea who will work on what card, but there have been some pleasant surprises recently. Also, if people are looking for something to do in the middle of the week, they’re now more likely to stray beyond their traditional domains than they had been.
• I’m pleased that we have knocked off many of the hygiene-related cards and haven’t added any new ones. So I hope that, soon, our source code will be in adequate shape where test-driven development and constant refactoring are enough to keep it well-maintained. (I do think we could stand to spend a little bit more effort on refactoring bad code whenever we’re in the neighborhood.)
• Several times in the last few months, my team’s priorities have been shifted significantly, in response to customer issues. I used to find that frustrating. Now I find that frustrating for about 10 seconds, then I say “wait a second, the customer is allowed to change her priorities, and it’s my job to make those changes as painless as possible, to not get us caught in the middle of long-term development that would have to get thrown away”. Then I notice that we’re getting more successful with the latter, and my frustration abates.
• My team members seem perfectly happy with using the cards, and it’s not introducing any significant overhead.

All in all, I’m happy with how things have gone. There’s nothing that I can point to that is a huge advance over the previous state of affairs; on the other hand, there are several small changes that I like, and I can’t think of a single negative aspect of using the cards. Which is pretty good, in my book.