malvasia bianca

As I said last month, we’ve finally started doing a full planning game; we did it again this month. And I’m really glad we did: for one thing, November’s planning rubbed in our faces some of the things we were doing wrong.

One basic issue, as I see it, was that we were focusing too much on using real units for our planning. We were doing lots of measurements, but at the end of it, the main thing we got out of our measurements was that, in a week, we spent a week working. Which isn’t very useful!

So now we’re giving up on measuring actual time; we’re simply estimating our tasks in points, but not measuring how much actual time a point takes us to do. Instead, we total up the points in the cards we finished that week, and there’s our velocity. Simple, much more useful than what we’d been doing.

The other improvement is that we’re getting a lot more serious about breaking up large stories into smaller ones: we’ve basically given up on the idea of a 3-point story (which was a story that we thought that a person could get done in a week doing nothing else), so now all our stories are either 1/2 point, 1 point, or 2 points. (A geometric progression; I don’t think that’s an accident.) This seems to greatly reduce our errors.

The upshot is that, in November, we included a significant slush factor for mistakes in our estimates and still didn’t get close to accomplishing everything that we’d planned, while in December we included no slush factor and are slightly ahead of schedule.

Some of that, to be sure, is due to external factors: in November, we were working in a bunch of new areas, so in retrospect it’s not surprising that we had pretty high startup costs. And then in December we were working on the same areas and made our estimates just before we started getting comfortable with them; as a result, several tasks that we estimated as 2-point tasks ended up being more like 1-point or even half-point tasks. (To be sure, there were still some estimation errors in the other direction. I’d be worried if there weren’t estimation errors…)

I’m also really pleased that we did a good enough job of preparing cards in advance that our Customer could pick all the cards for us to work on instead of him having to say “this sounds like a good thing to work on, pick 5 points to work on once you’ve got cards worked out”, and could do so in about an hour and a half. One of my top priorities before Christmas is to make sure we’ve done enough ground work so that we’ll be able to do the same thing in January.

The Customer also wrote three story cards during the December planning meeting, as a result of our insisting that he pick all the cards. (He’d also written a few cards before then in a previous meeting.) And all three cards have proven useful: two of them turned out to be for things that we thought software we were integrating could do but it can’t do, so I’m very glad we learned that now! And the other involved something that we’d implemented incorrectly and which had slipped through unit testing; oops.

And while we’re on slipping through testing: we’re still running into situations where we realize we haven’t written enough acceptance tests for a feature, we write an acceptance test, and it turns up bugs. I’ve loved my unit tests ever since I started writing them; now I love acceptance tests, too. If you’re ever programming with somebody else, the single most useful thing you can say is “should we write a test for that?”