Archive for September 2008
One of the first thoughts on hearing the word Scrum - 4 weeks to a Sprint. To some this is music to ears, but to others not so much. And who are these "others"? Usually, it's the Product Owners (PO). While developers want a sprint to be locked out, POs want to be able to add/remove/swap stories in it. Scrum's answer to that is simple - avoid it. If you can't avoid it, flush the sprint and restart. The inspiration behind that recommendation might have been to discourage changing the sprint in-flight.
Where's the Agility? Isn't a locked sprint bit contrary to the whole concept of agility? What's the point in locking out if the underlying philosophy is to be able to adaptive? Clearly, it's a conflict of interest between the developers and POs. One way to avoid it is to reduce the sprint length, to let's say 1 week. Now, this may be a mighty fine deal for the POs, but it not always the case for developers. One week may come across as a bit rushed to them to produce anything meaningful in some contexts. So, what's the best way out.
Multi Episode Sprint A good compromise can be a half-locked sprint. In a four week Sprint plan and lock the first two, plan but keep the last two open to changes. One of my colleagues at ThoughtWorks calls it an Episodic Sprint. If there are changes mid sprint, have a sprint planning meeting after the first two weeks to re-plan the remaining two. Episodic sprints, in my opinion, are a step towards creating a software development environment that prevents itself from being fed half-thought through and low priority stories but still accommodates for genuine changes. For teams that are just starting Scrum, I would highly recommend Episodic Sprints.