December 18, 2015
In theory, full agile/scrum with two-week sprints is a major boon for everyone. Engineering teams agree to what exactly is expected of them, and the business agrees on when to expect their asks to be complete. Reality is of course never quite that simple.
One of the core tenets of scrum is that you don’t accept a task into your sprint unless it is fully spec’d and completable. For instance, if you get a task to change the text color on the home page, but the new color is not defined, you can’t accept that task into your sprint because without that color the task is impossible to finish. If you receive the color after your sprint is started, you have two options: reset the sprint with the new task included (heavy) or add the task to stretch goals and the business owner can hope it gets done. Neither of those options are very palatable, and sometimes the tasks legitimately call for mid-sprint tasks (we’ve found that as we get closer to our events, such as the Imagine Commerce conference, quick-turnaround tasks come up frequently).
Some teams will abandon scrum in favor of another methodology, like kan ban, when this happens. Others will take on the tasks anyway, blowing their sprints. We thought there had to be a better way, so we came up with Fastpass. I’m not sure we’re the first to do this, or even to call it Fastpass, but I couldn’t find it in a cursory Google search.
Inspired by Disney’s ticket of the same name, Fastpass is where we take a portion of the team’s capacity and reserve it for ad-hoc tasks. Normally we’ll take 15% of our capacity and reserve it for Fastpass. So if we normally can accomplish 30 story points in a sprint, we’ll plan our sprint with 25 points and reserve 5 for Fastpass. Fastpass capacity may go up or down depending on what tasks might be in the pipeline – as we approach a conference date, we increase our Fastpass capacity from our normal 15% to say 30%.
In JIRA we have a custom field for designating a ticket Fastpass, and when we get one of those tickets we’ll pull it into the current sprint and complete it. Fastpass tickets have the same requirements as others – they must be estimated, they must be completable, and so forth.
We’ve also used Fastpass for critical security issues or paying off tech debt when nothing else comes down the pipe. Having the spare capacity really lets us focus on driving ahead without getting too caught up in a rigid by-the-book Agile/Scrum process.
The Agile Manifesto professes people over process, and with Fastpass we think we’re able to achieve that. Engineers still get a maintainable level of effort required from them, and the business gets critical tasks done without having to wait for another sprint. If you find yourself resetting sprints or taking on extra tasks out-of-band often, give Fastpass a try.