Last updated 13 February 2018.

What is a sprint?

A sprint is getting contributors together for a set amount of time – usually one to two days – and just creating code, docs, etc. That's it. You’re not teaching anything. Participants will learn from others as they go, but the focus is not on instruction. The goal is to create working software. Sprints are also sometimes called “code sprints” or “contribution sprints”.

Generic considerations for organizing sprints are described on the organizing sprints page. This page lists some considerations specific to code sprints.

In-person sprints

In person sprints are indisputably the most effective way to tackle difficult code challenges.

You have a strong meetup and you have a strong camp presence and now you want to get some work done. Or you have been coordinating among several leaders in a given area of development and it's time to get them in the same room working together.

Virtual sprints

While nothing's quite the same as being in the same room, it's not always feasible to bring together people from around the world. It's also possible to organize a virtual sprint. Here communication might happen through IRC in a designated channel with set times for participation. Ideally, if some participants are in the same region or city, they could arrange to get together in small clusters so at least some sprint participants are in the same room.

A virtual sprint requires a bit more coordination and imagination but can also be effective.


Talk about what is going to be done at the sprint. Defining some goals and communicating them ahead of time helps for focus and preparation. For example, you could have a sprint focused on improving core themes or documentation for a module.

Also try to define the minimum bar needed for participation. Unless you’re giving a newbie sprint, you need to communicate that this is not the place for newbies. If you’re coming to a theming code sprint, you need experience in theming. If you get a lot of people who aren’t up to speed on the code you’re focusing on, you pretty much have the first day of the sprint wasted. Everyone’s trying to figure out how things work, walking through the module trying to figure out what the functions are.

Make sure participants have access beforehand to the same files. If you’re going to be working off a single repository, make sure it’s available. If you’re not working directly off of Drupal git, make sure all participants have access and that you’ve tested your repository with multiple concurrent users.

Core Mentoring has a collection of information for sprint planning, useful for sprints expecting new contributors.


alimac’s picture

A Helpful Guide to Your First Drupal Sprint is a nice blog post that covers what to expect at a sprint.

cameroncb1’s picture

The link to A Helpful Guide to Your First Drupal Sprint ( leads to a Not Found page.

YesCT’s picture is a great blog about how experienced contributors and sprint leads can get ready for a sprint