Written by Domenic on Dec 18th, 2015. It was a Friday.
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 Fast Pass. I'm not sure we're the first to do this, or even to call it Fast Pass, but I couldn't find it in a cursory Google search.
Inspired by Disney's ticket of the same name, Fast Pass 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 Fast Pass. So if we normally can accomplish 30 story points in a sprint, we'll plan our sprint with 25 points and reserve 5 for Fast Pass. Fast Pass capacity may go up or down depending on what tasks might be in the pipeline -- as we approach a conference date, we increase our Fast Pass capacity from our normal 15% to say 30%.
In JIRA we have a custom field for designating a ticket Fast Pass, and when we get one of those tickets we'll pull it into the current sprint and complete it. Fast Pass tickets have the same requirements as others -- they must be estimated, they must be completable, and so forth.
We've also used Fast Pass 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 Fast Pass 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 Fast Pass a try.