malvasia bianca

For months, I’ve wanted my team to try actual XP/Scrum-style release planning; yesterday and today, we actually did it. I’m glad we did; if nothing else, it was quite interesting, and I think/hope it was productive. This planning is for a “release” at the end of the month that we’ll use for demos and trials and give to our external partners for integration work. (We do such releases every month.)

We don’t have an appropriate real customer to use for planning, so my boss was doing the Customer role. Which wasn’t completely ideal (a product manager might have been a better surrogate), but was good enough, and even had its advantages given the multiple teams working on the product.

We didn’t have an existing product backlog to work from, so we started by going through the new features that were high priority, and brainstorming each enough to come up with some tasks we could work on this month. Also, we discussed some things that we might work on other than new features: refactoring, fixing bugs, improving our testing. It is a flaw in our development that we have to do any of that outside the context of adding new features; we are flawed. (But we’re getting a lot better.)

Then he went through the tasks and marked them as priority top, middle, low. We then discussed how much work we’d do this month and the extent to which we habitually underestimate (like I said, we are flawed), and came up with a budget for our estimates this month.

Then he went away for a little while and we estimated the top and middle priority tasks, and came a proposal for how much we’d like to work on the hygiene tasks (refactoring, bugs, testing). We had been worried about external dependencies for some of the tasks; we talked about where we could minimize that and where we couldn’t. And there was one high priority area where we needed outside help to break it down into tasks, since it was in an area where another team had done most of the work.

Amazingly enough, the concrete top and middle priority items used up less than half of our budget; we put in a modest but nontrivial budget for the hygiene tasks, and that still left us with a noticeable budget for the vague high priority area. So we ran this by our Customer, and he agreed that it was a good plan.

I liked the outcome a lot. It’s a workable plan; there will be surprises, but I’m pretty sure we didn’t seriously over- or underestimate how much we can get done. We’ll make concrete progress in several important areas, including some areas that I’d been nervous about starting. We have some limits in place to discourage our desire to work on what we want to instead of what is most valuable for us to work on. We did a good job of analyzing possible roadblocks and working around enough of them that the remaining issues should be manageable.

There are some improvements we’ll want to make for next time. We spent too much time breaking down big issues into manageable tasks; in the future, that breakdown should be mostly done before the monthly planning meeting. So I’ll try to meet with my boss to do some more of that, so that next month we’ll be better prepared. And maybe my team can spend a little bit more time estimating the resulting tasks in advance, to further speed up the meeting. Having said that, though, while spending half a day on this is a big chunk of time, I’m almost positive it will pay for itself quickly: if it causes our team to spend even a day working on high-priority items where, left to our own direction, we would have worked on low-priority items, that’s a win right there.

I’ll make a Big Visible Chart out of this, we’ll break it down into weekly plans, and get going; I’ll report back at the end of the month!