Rethinking Sprints

Agile Scrum has taken the software industry by storm and sometimes it seems the entire development world works on a two-week, sprint based, clock.  But, do sprints really make us more agile?  How do sprints effect productivity?  Is the process overhead really as low as promised?  Let’s take a look at Agile Scrum — the pros and cons and some alternatives that may help your team become even more agile.

Because the terms ‘agile’ and ‘sprints’ have become basically synonymous, let’s first step back and see how they are related.  Agile is a methodology that includes concepts that encourage shorter development iterations, increased product owner feedback, full team involvement, and less rework.  Agile Scrum is the type of agile that utilizes sprints to do this.  Scrum is the most common form of agile, but it is only one of many approaches.

Agile Scrum accomplishes faster development time by shorting the development cycle to two-four week sprints.  It increases product owner feedback with end of sprint demos, involves the whole team through sprint planning sessions and reduces rework by focusing feedback on the previous sprint and catching problems early.

At the start of each sprint the team is asked to estimate the tasks in the backlog.  The entire team should agree on a number of story points (a unit of effort) that each task is going to require.  Sprints have a velocity, or number of total story points that can be allocated.  Once you’ve spent all your story points, work starts.  During the sprint you can watch how many story points are being completed on a daily basis (referred to as a burn down chart).  If you have a velocity of 100 points, using a two-week sprint, you’d want to see 10 points burned per day to know you’re on schedule.  By the end of the sprint, with perfect estimates and no issues, you will compete all your tasks.  You’ll then demo your results, get feedback, and start planning your next sprint.  While this of course sounds great, let’s look at what often happens when you put sprints into practice.

First, there is no such thing as perfect estimates and no unforeseen issues.  Anyone that has worked with sprints knows this.  You can work around some of these factors by padding estimates to account for any issues that may arise, however, that brings two social laws into the mix: Goodhart’s law and Parkinson’s law.

Goodhart’s law states that when a measurement becomes a target, it stops becoming a good measurement because employees will take action to make sure they hit that target.  Parkinson’s law says that work will expand to fill the time allotted for it.  Mix these concepts into a sprint planning session where your progress is measured by how well you’re able to complete all the tasks in a sprint, and it’s easy to see what happens.  Estimates are inflated to account for the unknowns that are bound to come up.  Then, because the estimates are inflated, the work will end up taking as much time as those new estimates.  In the end, it’s not uncommon to see one week of work take the entire two weeks of a sprint.  This inflation of estimations is almost entirely caused by tracking progress within a sprint and/or measuring the success of a sprint by how many of the estimated tasks were completed.

In addition, many sprints will encounter one or more tasks that can’t be completed at all.  When this happens, the task is removed from the sprint and, sometimes, a new task is added.  This new task needs to be agreed upon and estimated by the team, which takes time.  Sometimes, even when a task isn’t removed, a new task needs to be added mid-sprint.  The team can simply say no to the new task and add it to the next sprint, or they can decide on what needs to be pulled out to make room for the new task.  Both have negative consequences.  Saying no means the high priority task will have to wait a full extra sprint. Pulling something out can be disruptive and cause loss of productivity as well.  Due to inflated estimates, there probably is actually time to just add this new task to the current sprint, but the process doesn’t allow for this because each task is estimated separately and it’s not clear the time actually exists.

Other issues with using sprints include things like when a feature doesn’t fit into a nice timebox and you’re asked to split the tasks into smaller, arbitrary, parts that are all dependent on each other.  Or, when team makeup changes affecting your velocity in unpredictable ways.  Or, how bugs are estimated and added to sprints.  Or, the fact QA is often underused at the start of a sprint and overused at the end.  But, instead of continuing to list issues, we’re going to move onto how this can all be solved.

And, turns out, it’s pretty easy.  Drop the sprints and don’t track estimates.

Remember, sprints are not what makes a process agile, so dropping sprints is not dropping agile.  What it does do is remove a target that can no longer be gamed.  Productivity should be about how much you get done, not how well you estimate what you’re going to do.  So just how does sprintless agile work?  That’s what I’ll cover in part two of this article.