Code sprint five by five

Last week Development Services, in collaboration with colleagues in the University Website Programme team, helped run a code sprint with developers from around the University to work on fixes and enhancements for EdWeb, the Drupal-based content management system that underpins the University’s website.  This post gathers some technology-agnostic thoughts on what we did to prepare, and how we ran our sprint, that might be of interest to anyone thinking about running a similar event.


  1. What is a code sprint?
  2. Why run a code sprint?
  3. Five what by five what?
  4. Conclusion

What is a code sprint?

If you’re not familiar with Drupal, a code sprint involves getting developers together for a fixed amount of time to write Drupal code. Last year I wrote on this blog about our experience attending a Drupal code sprint at DrupalCon 2015.

Developing code in this way is common to many open source technologies and code sprints are not a concept unique to Drupal. A code sprint might be known in more general terms as a hackathon or a hack day.

Why run a code sprint?

To answer a question with a question, why wouldn’t you want as many knowledgeable and experienced brains focused on contributing to your software as you can get?  As a University, we’re extremely well placed to harness development skills from around our organisation; all we have to do is put in place mechanisms that enable those people to contribute.

Like many Drupal implementations, EdWeb combines code contributed by the Drupal community with custom modules and features. The Drupal community makes it easy to work with contrib module owners and contribute to Drupal code itself.  The vision for EdWeb, and one of the reasons for settling on Drupal as a platform, is that a parallel internal community might develop, allowing developers from all over the University to contribute to the custom modules and features in our central CMS.  Last week’s code sprint event borrowed from Drupal’s open source principles to pilot a process that we hope will act as a catalyst for further collaboration and become a regular component in EdWeb’s evolution.

Five what by five what?

That’s enough about EdWeb and Drupal for now!  There is a wealth of useful information on running a Drupal code sprint on  If you’re running a Drupal event, that’s the best place to look for detailed guidance. The aim of this post is to extrapolate some common principles that ought to apply to collaborative code sprints or hackathons in any technology. We run many IT services around the University; it’s in our interests to think about how we might apply similar techniques to other software we manage.

To give some structure to these thoughts, I will focus on five headings and suggest five key points relating to each that seemed to me to be critical to our success in getting through the sprint and having fixes and enhancements contributed by participants to show at the end of it:

  1. five key preparation steps;
  2. five considerations on what to cover in your code sprint;
  3. five key roles;
  4. five things to include on the day;
  5. five follow-up actions.

I should note that these are the thoughts of a software developer, so my perspective will inevitably have a technical bias and your mileage may vary in terms of what seems most important!

Five key preparation steps

Preparation is absolutely key to a successful code sprint.  A code sprint is like everything else in life: you only get out what you put in.  The more you do to prepare for your code sprint, the more chance you will have of participants successfully contributing on the day.

  1. Know your participants
    • As this code sprint was our first, we sent out a short survey to participants to gather some information that would inform the selection of work to cover in the code sprint.
    • Useful things to know:
      • what participants hope to get from the day;
      • how familiar they are with the technologies involved in the sprint and any development tools/frameworks you’ll be using;
      • how familiar they are with the software (are they themselves users as well as developers?).
    • The information also helped us gauge how to structure the day, for example how much time to allow for setup, how much of a technical introduction to include, etc.
  2. Book a suitable space
    • You’ll need a room with plenty of space for participants to work that is flexible enough to allow for developers to work individually or in pairs/groups.  Make sure wifi is available, and that there are enough power points in the room. Have a projector available for any demo or intro that is required. Ideally there should be an area available with a smaller wall-mounted screen to allow participants to talk through more complex issues in a small group. Aim for a space that allows for break-out sessions, and for people to lunch together so that conversations can continue during breaks.
  3. Document preparation steps for participants
    • Publish details of any preparation participants need to carry out as far in advance of the sprint as you can manage.  Steps might include registering to use your code repository, or setting up a local development environment.
  4. Set up a chat group
    • Set up a group or channel for communication as soon as you have a list of confirmed participants.  We used a Slack group to allow participants to ask questions in advance and get help preparing for the code sprint. It was also an extremely useful tool for participants to communicate on the day, particularly to share code snippets, files, etc. when working in pairs or small groups.
  5. Publish a running order for the day
    • Provide an outline of the structure for the code sprint in advance so that people know roughly what to expect, but don’t be too rigid about the structure. The schedule should be flexible enough to allow for change on the day.

Five considerations on what to cover in your code sprint

By identifying a clear set of tasks to tackle at the code sprint, you will provide a focus for the code sprint that will help you get the most out of the day.

  1. Review your product backlog
    • If you’re actively developing the software that is the target of your code sprint, you will have a backlog of work that might be included. This is the best source for an initial list of code sprint candidates. Try to eliminate any questions or unknowns relating to the issues you want to cover to maximise the time spent coding.  For example, identify any potential UX issues and, as far as possible, settle on a solution in advance.
  2. Canvas suggestions from your participants
    • Ideally your code sprint should focus on what participants want from the day as well as on improving your software. One way to achieve that is to canvas suggestions for enhancements from participants; your software will benefit from their ideas, and they will have an extra incentive on the day if they have a personal interest in the work they are doing.
    • For our code sprint, we included both tasks drawn from the EdWeb product backlog, and suggestions from developers around the University who participated on the day.
  3. Consider the experience level of participants
    • Construct your list of confirmed code sprint tasks based on what you know about the participants who will attend.  If the group consists largely of beginners, ensure the tasks are small and self-contained, and include as much information as you can on how to implement the change; if you have a range of experience levels, vary the level of task complexity and the detail of any technical notes accordingly.  You will need technical input from developers familiar with your codebase to weigh the list of proposed code sprint candidates against participants’ experience.
  4. Set realistic targets
    • For each code sprint candidate task, identify a realistic target to achieve at the code sprint.  This might range from implementing and testing a complete solution to carrying out some R&D to answer a few technical questions.  If there is a candidate task for which you can’t identify a target that is achievable at your code sprint, discard it as it will only waste valuable time on the day.
    • Among our code sprint tasks, many were small, simple changes suitable for beginners for which our target was to implement and test the changes required. However, a few were investigation tasks requiring some technical discussion and perhaps a bit of collaborative R&D which we did not expect to result in a solution on the day, but which will ultimately feed into future development work.
  5. Publish a list of confirmed code sprint tasks in advance
    • Create a space that is easily accessible to your code sprint participants and publish your confirmed code sprint tasks as early as possible before the code sprint.  This gives participants a chance to consider what they might tackle at the code sprint, and even do some preparatory work in advance. Keep the list up-to-date as you identify more tasks, and use the chat group you set up to let code sprint participants know when things change.

Five key roles

The most important people present on the day are clearly the code sprint participants! However, there are a few specific roles we included in our code sprint. These roles were influenced by the fact that this was our first code sprint and quite a few of the 8 developers present had little Drupal development experience and no previous experience contributing to EdWeb.
  1. Product owner
    • This role is critical if you’re to avoid decision-making bottlenecks that prevent work being completed on the day. In an open source community, the concept of product owner doesn’t really exist as the software is owned by the community; in all other situations, someone needs to be empowered to answer questions about functionality that arise on the day.
  2. Technical facilitator
    • This role involves introducing the tasks to be covered and giving technical guidance throughout the day: helping participants choose what to work on, answering questions, carrying out code reviews, handling pull/merge requests, etc.
  3. Technical expert
    • This role covers more in-depth technical discussion of the solution for a particular issue.  The person’s expertise may be in coding, or you might want to have a UX expert present if your sprint involves a lot of front-end development or design. The important thing is to allow for longer, more involved technical discussions in a way that doesn’t interfere with progress for other sprint participants. If your code sprint involves a lot of experienced developers, they will probably fulfil this role themselves!
  4. Progress monitor
    • This role involves tracking work in progress and keeping momentum going throughout the day, for example by ensuring that a piece of work is picked up for code review and testing so that it can be marked as complete.
  5. Setup asssitant
    • This role caters for any setup issues that arise.  The work involved may be quite light if you’re dealing with a relatively established group of developers, so could be carried out by one of the code sprint participants.
Each role outlined above might be taken on by only one person, or you might have more than one person fulfilling a role, depending on the size of your sprint and the experience of participants. For our pilot code sprint, the same person fulfilled the ‘Technical facilitator’ role and the ‘Progress monitor’ role, but we had a separate person acting as ‘Technical expert’, which allowed participants to engage in more involved discussions about particular functionality and do some R&D that will feed into future development work.  There will be a degree of overlap between all roles; the important thing to be sure of is that you have the people you need to fulfil the roles you need at your code sprint.

Five things to include on the day

  1. Setup time
    • No matter how straightforward preparation is for your code sprint, there will inevitably be some setup issues on the day. In addition to dealing with technical hitches, the setup time can be used to go through the issues for the day, and to allocate the first batch of work to individual developers, pairs or groups, depending on the size of the task and how people prefer to work. You might want to include a short demo session at the start of the sprint if you have a few beginners in the room as we did, but that should be optional to allow the more experienced to progress.
  2. Simple, high level issue tracking
    • Set up a simple, paper-based tracking system to track the progress of code sprint tasks and give a high level overview of how things are going.  For our code sprint, we used a whiteboard marked up with suitable Kanban stages, and moved cards representing each piece of work through each stage as the day progressed. Coloured postits or stickers marked allocated cards with the name of the developer(s) currently working on them. Everyone was encouraged to interact with the board, but at least one designated person kept an eye on progress to keep momentum going.
  3. Detailed issue tracking
    • A tool such as a Kanban board provides a high-level visual tracking system for the day, but you also want to have an electronic record of progress so you have a clear picture of what was done.  Ideally, you will be able to allow participants access to an issue tracking system that is suitable for your software, and encourage them to use that tool to document the work they do during the code sprint. This is the approach we took for our code sprint. Alternatively, you might have a scribe update your issue tracking system separately.
  4. Catch-up slots
    • Include one or more brief slots for everyone to share progress. We included a fifteen minute slot after lunch, similar to an agile stand-up meeting, where each participant gave a quick update on how work was progressing.  We also had a slot towards the end of the day where we identified which tasks were complete, and agreed next steps for any tasks that were started but not completed.
  5. Retrospective
    • Allow time at the end for participants to share their experience of the day.  This is an ideal opportunity to gather feedback that might inform how you run future code sprints.  It’s also a chance to celebrate the achievements of the day!

Five follow-up actions

To get the most out of the code sprint, work does not stop when everyone leaves the code sprint venue.  Following our own code sprint, there are some key things we have identified as follow-up actions, which we will progress in the coming days and weeks.

  1. Follow up on agreed next steps
    • Set aside time to follow up on any agreed next steps for code sprint tasks.  In our case, this will involve gathering all of the fixes and enhancements developed at our pilot code sprint together and putting them through the standard automated testing and deployment process for EdWeb.  We also have some tasks that require further work following up on R&D, and some tasks which were not finished on the day but only require a small amount of additional work to complete.
  2. Survey your participants
    • Even if you held a short retrospective at the end of the code sprint, it is useful to give participants an opportunity to provide further feedback after they’ve had time to reflect on the day.  As we hope to make use of code sprints in future, this additional feedback will allow us to review and refine how we run things on the day.
  3. Refine your preparation documentation
    • Based on the technical questions and setup issues that you encountered on the day, update your code sprint preparation docs to smooth the process for future code sprint participants.  The goal is to answer questions before they are asked and avoid holding up developers on the day with commonly asked questions, allowing them to focus on the task at hand and cut some code!
  4. Refine your setup processes
    • To make it as easy as possible for future code sprint participants, reflect on the setup issues encountered on the day, for example clunky aspects of the setup process, and refine your processes to iron out difficulties. For us, this means making it easier for a code sprint participant to get up and running with a local development environment, something that will help our permanent development team as well as future code sprint attendees!
  5. Publish your progress!
    • When you next issue a software update, make sure you note the contributions made at your code sprint, and credit the participants!


If you have access to a wide community of developers with a broad range of skills and experience who are outside of your core development team, you can use code sprints as a tool to harness that experience, benefiting participants, who have an opportunity to influence and participate in the development of the systems they use, whilst also improving your software. If you’re lucky, code sprints will be a catalyst for a richer, more collaborative development community.