The Root Of All Evil in Scrum

(I originally posted this on my MSDN blog.)

Sometimes the Scrum process kind of breaks down.  Maybe there’s confusion over backlog items, or some people end up with nothing to do, or there’s a general sense of spinning the wheels but not getting anywhere.  I’ve seen these kinds of symptoms in my own work and observed them in other teams.

Personally, I think the most common cause for general malaise in the Scrum process is a lack of clear, tight focus on delivering business value.  Whenever you let the team go off the rails and start building infrastructure components with no immediate consumer, or you invest a lot of effort into tracking hours spent on non-development tasks, or you find yourself at your end-of-sprint demo talking a lot about work you did but having nothing to actually, um, demo – pain is sure to follow.

If Scrum isn’t working for you, the first thing you should do is see if you can draw a clear line between every task on your sprint backlog and some concrete, deliverable feature that your customers(*) actually care about.  If you can’t, stop and clarify your goals until you can.  If there’s no believable rationale for a particular task that your customer would get excited about, just drop it.  It’s not important and it’s distracting you from your mission.  If you don’t have a plan for delivering something that’s done, demo-able, and potentially shippable at the end of the sprint, narrow the scope until you know how to do so.  If you have some kind of required process in place and you can’t succinctly explain exactly how that process enables you to deliver working software in a better, faster, and cheaper manner, then drop the process.  It’s not helping.

It’s not always easy to cast things in terms of measurable business value.  Sometimes it takes a lot of skill to do so in a meaningful way.  Thinking about narrow vertical feature slices helps, but sometimes it takes a lot of hard work to identify the appropriate slices.  In the end, though, it’s absolutely worth it.

(* Of course, you also need to keep a complete list of your customers in mind.  An end-user won’t directly care if your project has good diagnostic logging, but your Operations team definitely will.  They’re customers too!)