My one weird rule for a stumble-free sprint

sprintSo 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.

My one weird rule for a stumble-free sprint

3 thoughts on “My one weird rule for a stumble-free sprint

  1. Great article!!! On a side note, I would like to see a branch of Scrum come into being (which I shall call “Cyclic Attrition”), in which if a customer forces me to expand my sprint’s scope or increase the number of sprints, then I exponentially increase the required 1-to-1 interaction with the customer for Acceptance Testing. Never had a chance to try it yet, though, because I’m not sure who would become insane first. 😛


  2. I’ve worked for a company that should have used your 1 Weird Rule! They followed more of the “Scrummerfall” approach and it’s basically almost completely defined by your silly sprint lane example, except that was the schedule for the entire time between release versions (usually about a month). The only time the developers were given actual work was sometime between Subtask 2a and 2b. This lead to horrible “dry periods” where the developers were sitting in the chat rooms, waiting for the BA’s to get through their closing “tasks” (quotation marks because I even saw tasks like “Convert Requirements Doc to Google Docs”), then plan,THEN assign the next wave of issues.

    During the dry periods, you could sometimes get away with taking an issue from the backlog on your own initiative, but this was usually met with “Wait a minute, where did the decision come from to spend cycles on this?” So they would essentially rather you did nothing and pretended you were busy while they managed their “sprints” than actually get any work done.

    Liked by 1 person

    1. forrestbrazeal says:

      Oh yeah. Meta-sprinting is the worst.

      Honestly when I read back over this post, I thought for a second, “this whole thing is a truism, is it really worth posting?” apparently it is. haha


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s