Scrum thoughts: Fixed feature set vs. fixed time
Series [ Scrum Thoughts ] Tags [ backlog, estimation, iteration length, product owner, release management, Scrum, timeboxing ]
I think we’re going to enter into an interesting discussion with our product owners where they would like to propose moving away from a fixed-length (in time) iteration model to a fixed feature set model. The claim is that it is too hard to maintain a release roadmap when the set of features that comes out of a sprint is fluid.
[Sidebar: our sprint teams routinely overestimate how much we can accomplish, so items are always falling off the end of our sprints. We’ve mitigated this somewhat by at least marking the bottom part of our sprint backlog as “low confidence items”, but the truth is we rarely get to those items, i.e., we never totally finish our sprint backlog.]
So I think there’s a valid complaint here, however, I think it is misplaced. We also never actually get far enough ahead on story point estimation with the product team to have more than a sprint’s worth of rough LOEs on things. So I’m not sure that any roadmap that would get produced would have any grounding in actual engineering estimates.
So now that I think about it, this is probably more of a version numbering problem more than anything else. We increment our version numbers with every sprint, and furthermore release the output of every sprint to production. So I think the issue is that, for internal consumption’s sake, our product owner can’t say “the following features will be in 1.7, these other ones in 1.8, etc.”
It sounds like what we want to do is to choose a set of features for a release, and then simply run iterations until either that feature set is complete, or the product owner decides that the output of some iteration is good enough to release. Naturally, of course, now that I’ve written this out, this is the by-the-book definition of how to do release management with scrum. Not quite sure how we got away from doing things that way.
I’m pretty convinced we should stick with the fixed-length iteration method, mainly for the reprioritization effect it has at planning. For every sprint where we had carryover, big chunks of that carryover were routinely deferred down the priority list from sprint to sprint, suggesting that we actually produced more product value than we would have if we had just finished each sprint straight out.