Rethinking Sprints

In part one of this article we talked about Agile Scrum: what it is and how the overhead and measurements of sprints can lead to lower productivity.  In part two we’re shifting focus to discuss how dropping sprints can increase productivity, reduce process overhead, and generally make your team even more agile.  One thing I want to note, while Scrum uses sprints and is one agile methodology, there are a lot of sprintless agile methodologies out there as well.  What I’m about to describe most closely matches Kanban and you can make use of most Kanban tracking tools to implement the following methodology.

The most important part of using agile without sprints is to manage the backlog.  There should be a single list of tasks and they should always be in priority order.  The only real difference between this and a Scrum backlog is that you don’t pre-pull tasks.  Instead, the day-to-day management of the backlog should be handled by the product owner and project leads.  And, it can change as often as needed — sometimes several times a day, sometimes once a month.  If a high priority bug comes up, just add it to the top of the backlog.  Find out a task isn’t ready to be worked on yet?  No problem.  Just move it lower in the backlog.  The backlog is the plan and the plan is designed to be flexible and changeable at any time.

Estimating tasks is no longer done with story points or time, but rather the general size of the task (often referred to as t-shirt sizing).  If a task is “less than a day” it’s small.  If it’ll take “about a day,” it’s considered medium.  And, if it’s going to take “more than a day,” we call it large.  For the extremes you have extra small, “won’t take more than an hour,” and extra-large, “a week or more.”  These are not precise for a reason.  In general, the more granular the individual task estimate is, the more inaccurate the sum of those estimates.  How many “small” tasks can be completed in a day?  More than one and likely less than eight.  If I say a small task will take four hours however, it will always be two tasks completed in a day (refer back to Parkinson’s Law).

Once you have a prioritized backlog, developers pull from the top of the backlog when they are ready to work on something new.  It’s also recommended that any task that takes more than a day to complete should require a daily update on progress.  Scrum meetings, or “stand-ups,” are still valuable for this reason.  Short meetings that simply state what you did and what you’re going to do, as well as any issues you may have run into, are very valuable to the team as a whole.  Basically, this is pure continuous development.  As long as there is a backlog of tasks, developers will always be completing a task and moving on to the next.  There is never a time when a developer will say, “I’ve got all my tasks done,” unless of course you’ve come to the end of the backlog.

But, what about releases and how does a project manager know what is coming up?  Where sprints have a velocity, sprintless will have a throughput, or an average number of tasks that get completed each day/week/month.  Simply counting down the backlog list and drawing a line will give you a good idea of what will be done within the next week, two weeks, month, etc.  There may be exceptions if you have a greater number of “large” tasks, but a good rule of thumb is to commit to 80% of what your average is and more often than not, you’ll over deliver.  So, if you average 20 tasks a week, then the top 16 is what you can commit to having done by the end of the week.  How is this different from sprints?  Mindset.  You don’t try to target 20 tasks a week.  It is not a target, it’s a rolling average.  And it’s not a metric that should be reported, it’s simply a guide based on what you did recently to predict what you’ll do in the near future.

As for releases, choose dates that make sense for your team.  A good cadence to keep is about every two weeks, which allows for enough new work to be evaluated and also, if something needs to be reworked, it’s recent enough that it’s fresh in the team’s mind.  It should be noted that QA is part of this continuous process as well.  They test tasks as soon as they are complete and, because tasks are always being worked on and completed, QA always has something to test.  Before a release, code is branched and QA is given time to do a full regression on that branch (while development continues on the development branch).  Once QA signs off, the code is released and can be demoed, beta tested, or fully released.

What about the retrospective?  For starters, to set the stage, a retrospective is a meeting that happens at the end of a traditional sprint to talk about what went well, what didn’t, and what should change.  If these meetings work well for your team, continue to have them.  But they don’t need to be limited to a sprint, nor do they have to be on the same cadence as your releases.  Like everything, when you go sprintless, the cadence of your meetings should adjust as the project needs adjust.

I’ve been using this process for the last three years, and the lack of overhead is freeing.  More work gets done with less micro managing and it’s far easier to accommodate ever changing requirements and teams.