Last updated 20 May 2016.
Printed sprint task cards will have a link to this page, or the per-task anchors below.
This approach to running a code sprint could be described as a very lightweight form of "gamification".
- On arriving at the sprint, participants were presented with a small range of "roles" to choose from to match their skills to. "Developer", "Tester", "Builder" etc.
- For each role there was a unique game-card - listing 4 or five small tasks they should be able to achieve within the sprint session.
- When a sprinter had achieved each of their tasks, they were awarded a nominal prize in the form of a tag for their conference lanyard : "I'm a Drupal8 Tester!"
A key condition was that to achieve a task it should be done for the first time at this sprint. The goal being to ensure that everyone finished the day having achieved something new. Several bonus tasks were available in each role also, for those who had already completed earlier challenges.
Important: The roles are not ranked in any order - they are just different but equal.
That's really all there was to the framework, but it provided a little structure and some meaningful goals for a sprint, while taking some advantage of being in the same room physically instead of using an online leaderboard or remote task management software.
Running the sprint
Response to this structure when we started it at DrupalSouth was very positive, as it easily answered the big questions like "What should I do? Where should I start? What is expected of me?". It supported an all-day sprint schedule where people could drop in and get started at their own pace, without needing presentations or group tutorials. And of course participation was totally voluntary and nobody had to play if they didn't want to.
People at a table were able to assist peers by referring to "what task are you having trouble with?" rather than "what are you trying to do?". This made it easier to identify individuals who could pair up or troubleshoot specific steps.
IT workers are notoriously non-responsive to material rewards as incentives - the idea of competing for a "prize" can actually be a turn-off. Keep the rewards as nominal as possible. We are not here to earn "things". The act of completing a task was its own reward.
On the other hand, achievements that involve bettering yourself, or earning recognition and kudos within the Drupal Community are often rated highly (while at the same time many IT folk are modest or shy, especially as first-timers), so make it visible. If it's a sticker or a badge, actually stick it to their shirt, bag or lanyard directly, don't give them something to hide in their pocket!
At DrupalSouth we just clipped small tags made of light card onto the sprinters lanyard, and we heard back at the end of the conference that many beginners had been noticed, and even congratulated and thanked by other developers who noticed them! This was huge. Feedback showed that this had a huge effect on the confidence of these first-timers.
( Also, you don't need to budget for prizes! )
Here is a link to cards used at DrupalCon Amsterdam.
The original cards and tags from the 2014 DrupalSouth Core Sprint are shared as GoogleDocs as
Developer, Tester, Contributor & Patcher task cards and Builder task card and lanyard tags. You are free to copy, edit and re-mix these templates, or just develop your own, no rights reserved.
Print them out!
A key part of the "sprint card" approach is the physicality of the task. It makes a change from online-only work, and plays with the fact you are finally in a room with other developers.
- It's something to hand to people as they arrive, a prop to establish contact with first-timers, and engage them in stand-up discussion instead of directing them into their own screen.
- Sprinters on laptops don't have extra screen space.
- People can physically claim a card or tick tasks off.
- Mentors can consult the checklists directly, without needing to use a screen.
- It gets sprinters to share space with each other, by interacting with other folk at the table over a shared card instead of their own screens.
The cards should contain short bullet points with easily understandable steps, and not too much detail. The card tasks describe what you should do.
Each card should probably refer to a corresponding task page (either this page, or drupalladder) that then describes how to achieve each step.
Printed Task : Install git on your local machine.
Web Page Detail: Select and download a git tool for your operating system. Install it and get familiar with its options. Ensure that commandline support is working for you (Typing
git --version in a terminal window succeeds).
Re-use existing help pages, don't write a new one
Web URLs on printed paper are not very helpful, links on web pages are.
Resist the urge to write too much on the task detail pages - you should try to find and link to (and maybe even improve) the copious already-existing documentation in the Drupal handbooks (as in the "Installing git" link above).
The drupalladder approach to tutorials, with short, discreet steps and measurable goals is suitable here. The Drupal Contributor Tasks are also good matches as tasks to create cards from - Link directly to these task pages and use the same descriptions and terminology.
If you feel the instructions could be clearer, please post a comment to the issue: Contributor role cards for booth (#2269681) where we are working on the task cards content and translations or collaborate via the GitHub repository.