- he adds something to the backlog
- if it's a story, they estimate it by "points" (1, 2, 3, 4)
- if it's a bug, there's no estimate
- he orders the backlog
- they work on the top thing
- when it's done, they mark it complete
He's welcome to alter the backlog at any time, including interrupting the current thing. Each week, the tool spits out the number of points completed in the previous week and a rolling average of the first three weeks.
It all sounds great.... but it turns out release planning is a huge pain.
Let's say it's Thursday and our backlog looks something like this:
- X (needed for client B on Monday)
- Y (absolutely essential for client A on Tuesday, and if it's finished Friday I can use it over the weekend so that I'm not in a rush to get it ready for the client)
Well, now, that's an interesting problem. On the surface, it should be X followed by Y, since X has to go to a client before Y. But there are a lot of meetings Monday and it would be really nice to have Y for the weekend. So that sort of makes Y due on Friday, and so it should go before X.
It's Thursday, and we have two days before the weekend. Maybe we can get both X and Y? Let's check our velocity.
We did 18 points last week. Our rolling average is 21 points, but it's been trending down. We've done 19 points so far this week. Well, shoot. We're already off trend; we're going to be up this week. That means I really don't know whether they'll finish X or Y or both.
(By the way, the team finished both X and Y. All the worry for naught!)
Now, release planning is always hard. And this dev team has definitely made it the client's problem - hence my friend's dilemma. But a one-at-a-time backlog makes it hard to plan sets of work in the short term. In the long term, planning works okay - the averages bear out. In the short term, though, it's hard, because it's really just a guess.
The bad news it, it's still a guess. The good news is, there are things you can do to mitigate those guesses:
- The most obvious is to not cut things so tight. Give yourself more of a buffer. This isn't always possible, but there's no reason to wait until the last minute when you do have advance notice of a feature for a customer for a date.
- Consider "non-point" items (bugs, meetings) in the count of the backlog. For example, it's possible to post-facto assign a point count to a bug ("this was 1 point of effort to fix"), and use that to calculate an adjusted velocity.
- Add "customer points" to your stories in cases where you have to do something after the story is finished (e.g., item Y in the example above). Some stories are done and there's nothing else for the customer to do before it goes live. Other stories have customer work that's done afterward. Effectively, this increases the overall size of the story. So in your customer backlog, it has to show up earlier... which means it has to be ready earlier in your development backlog.