So I’ve been thinking a lot about the scrum methodology lately. I’ve worked at a couple of places (including my current job) where it’s heavily utilized, and naturally I’d like to get the most out of it that I can.
To sum up the link above in my own words, if you need a quick refresher: The scrum methodology is an agile development model involving short burts of work (sprints) toward a well-defined goal, punctuated by regular “standup” meetings where sprint participants give brief updates about their progress on their assigned tasks or “stories”. Each sprint ends with a review and retrospective period containing demonstrations of finished work and analysis of the metrics generated during the sprint. The idea behind the model is to increase productivity across a larger development team while quickly identifying and eliminating any stumbling blocks.
Sprints can be a great motivational and management tool, but they can also cause a lot of problems if they start to drift from their intended purpose. In order to help me keep my eye on that purpose, I’ve developed the following rule.
The 1 Weird Rule For Great Sprints:
The ratio of “actual work accomplished” to “sprint tasks completed” should approach 1:1.
This is a fancy way of saying that sprint metrics should reflect reality. After all, the scrum methodology is just a framework to make real work a little easier. If the burndowns and other metrics in the sprint retrospective show that a large number of stories have been completed, but little work has actually been done (or vice versa), the sprint is not a helpful tool.
The 1 Weird Rule might seem obvious, but I struggle with it sometimes, so I suspect other people do too. Here are three simple applications of the rule that have helped me.
Weird Rule Application 1: Don’t close sprint tasks until they’re really done
We’ve all been there. Your sprint story says “Implement the new widget”. Although you’ve written the widget code, it took a little longer than you planned and you haven’t had time to fully test everything yet. But the sprint ends today and you’d love to mark that big story “resolved” so it doesn’t screw up the metrics. Maybe you can just complete the story for now and create a new task for next sprint called “Test the widget”.
The problem with this little trick is that when you originally estimated your commitment for the implementation story, you committed to the full implementation, including testing. When you revise the amount of work the story encompasses, but don’t change the implied scope of the story, your work-to-sprint-task ratio goes down and the 1 Weird Rule is violated. If your team as a whole makes a habit of fudging stories this way, the sprint stops being a good reflection of the team’s progress and your various metrics–however excellent they may appear–lose all meaning.
Weird Rule Application 2: Change sprint scope if necessary
This is kind of the reverse of the previous application. Mapping out sprint tasks ahead of time is great, but life doesn’t always cooperate. Production issues interfere with development time, unexpected prerequisites crop up and often you’ll find yourself halfway through a sprint and barely started on your “official” tasks.
The appropriate response to this situation is not rushing to complete stories in a slipshod fashion. If you run into unforeseen work in an existing sprint task area, add it to the backlog and pull it into the active sprint as you have time to deal with it. You definitely don’t want to complete additional work “off the record” without adding it to the sprint. If you do that, your work-to-sprint-task ratio will actually be greater than 1:1, violating the 1 Weird Rule and artificially deflating your sprint metrics. Again, let me repeat that there’s nothing bad about sprint metrics; so long as they reflect reality, they’re awesome. So make sure you log all the time you spend working on sprint issues, even if it means expanding or shifting the sprint scope from your original plan.
Weird Rule Application 3: Don’t sprint in circles
Imagine this silly sprint lane:
Sprint Story 1: Plan Sprint Stories
Subtask 1a: Plan Sprint Story 1
Subtask 1b: Plan Sprint Story 2
Subtask 1c: Plan Sprint Story 3
Sprint Story 2: Manage Sprint Stories
Subtask 2a: Update Sprint Story Times
Subtask 2b: Attend Sprint Standups
Subtask 2c: Prepare Sprint Story Demos
Sprint Story 3: Close Sprint Stories
Subtask 3a: Close Sprint Story 1
Subtask 3b: Close Sprint Story 2
Subtask 3c: Close Sprint Story 3
The owner of these sprint stories is contributing nothing of value to the development effort, no matter what the sprint metrics may say, because he’s not actually doing anything–just chasing his tail through the sprint lane. In 1 Weird Rule terms, his work-to-sprint-task ratio is a fat zero.
Sure, there’s a certain amount of administrative overhead when planning and implementing any sprint cycle. That’s why the 1 Weird Rule says the work-to-sprint-task ratio should “approach” 1:1, not equal it. But if too much of your time is given to managing these “meta” tasks, the sprint gets unnecessarily cumbersome, and you should reevaluate how much effort is being spent in maintaining sprint infrastructure.
What are your thoughts on the 1 Weird Rule? Do you have any “pet peeves” about the scrum development model? Let me know your thoughts in the comments.