Sprint and Startups

Spints are FUN and when startups start breeding, smelling and living on Sprints, they inherit a culture and environment which is very hard to beat. A lot of us praised Facebook when they went into a coding marathon just before its IPO to showcase its proud culture. But what is it so good that programmers around the world have started praising such a culture.

To be very honest, i tried to imbibe such a culture in my current organization but in vain. Sprints is just about a culture- a culture to be the proud crown of many many startups and I am very proud to have seen and been a prt of few of them with my friends in the past.

So, this time I though about taking some time out and giving people a perspective of a sprint.

What is a sprint?

A sprint is getting people together for a set amount of time – usually one to two days – and just working on some aspect of code, design or a task. Ideally, participants will learn from others as they go, and the goal is either to get some specific work done, mentor new contributors, or both. We choose to gather in a sprint format because:

  • It’s fun – sometimes it is nice to have some camaraderie while working.
  • It’s satisfying – the group can see the progress that was made at the end of the sprint.
  • It’s a good way to get a focused task done (though some sprints are more general and some are more focused).
  • Participants can get their questions answered immediately instead of waiting for an answer in an issue queue.
  • Participants can learn from each other.

There are two types of sprints: in-person sprints, where you get everyone together in one room, and virtual sprints, where you get people together on IRC or another online resource. In-person sprints are the most powerful and if organized and used properly, becomes the most powerful bread and butter of a startup. We try to describe how a in-person sprint can be organized, along with some considerations that are common to both types.

Organizing a sprint in general

This section lists considerations that apply to both in-person and virtual sprints.

Goal, tasks, and participants

The first step in organizing any sprint is to figure out what the goal is, such as “Mentor new contributors through contributing their first Code”, or “Write code for the new feature”. Once you have a goal, that will probably help you determine a list of tasks for the sprint, keeping in mind your intended participants. For instance, if you want the sprint to be open to new contributors, you will need to have some tasks defined for them to do. On the other hand, if your sprint is limited to a few hand-picked participants who have been involved for a while already, they may already know what tasks need to be done.

Issue tag

Many sprints also create an issue tag. The coordinators can tag issues ahead of time with this tag, to help sprint participants find issues to work on. And they can ask participants to tag issues they worked on during the sprint with the same tag.

Coordinators and mentors

It is helpful to have some experienced people participating who can mentor others (unless everyone who will participate in the sprint is experienced already). For a small sprint, one coordinator may be sufficient. For a large sprint, it is helpful to have about one “cat herder” (coordinator) for each 10 people or so, to be there to answer questions (or find answers), get new people who show up going, keep things moving, etc.

Central web page

It is very helpful to create a web page for coordinating the sprint. On this page, you can describe the tasks that need to be done (or link to their descriptions elsewhere), link to an issue search for your sprint issue tag, and have a Resources section with links to repositories, helpful background information, etc.


Announce your sprint by posting an “Event” on groups.

In your announcement, list:

  • Time/date
  • Location and directions
  • Attractions (free food, rock stars in attendance, etc.)
  • Focus, if there is one
  • Qualifications needed for participating, or who is invited to attend
  • Etiquette statement

You may also want to post your sprint on other calendars like facebook, twitter , etc.


It is important to have an appropriate space for an in-person sprint. Features:

  • Wi-fi access
  • White board and/or projector
  • Enough chairs and tables for everyone – preferably tables where about 6-10 people can sit and collaborate
  • At least one key participant/mentor

Supplies, food etc.

If you provide on-location lunch at the sprint, people can continue to work, talk, and collaborate during lunch instead of leaving and coming back, which can give you an extra hour or two of productive work time. On the other hand, at dinner time in an all-day sprint, people are likely ready to have a break. Having snacks and coffee on-hand is also helpful.

Supplies list:

  • Whiteboard or easel pad, markers
  • Cards or paper for doodles/sketches, pens and pencils (possibly colored)
  • Name tags, and perhaps some kind of sticker or special tag for coordinators (for large sprints)
  • Sticky notes: you can put issue numbers or tasks on sticky notes on a board, and people can go pick one up to claim it as their task.

Day of the sprint

  • Post signs at the building door leading people to the sprint
  • Post directions to bathrooms and WiFi on the whiteboard in the sprint room

Code sprints

Probably, the most vital of all the sprints for a startup are the code sprints. So, what is it? A code sprint is getting developers for a set amount of time – usually one to two days – and just writing code. 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. Code sprints are also sometimes called hackathons or codeathons.

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.


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 UI for management interface.

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 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.

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.

Roles at code sprints

There are lots of roles that people can take in code sprints. Yes, writing code is the most obvious, but there are also ways that non-coders can help.

Here are some of the typical roles for code sprints, along with tips on how you can get yourself ready to participate.

There’s some preparation that all sprint participants should do:

  • Read any documentation posted ahead of the sprint.
  • Participate in any discussions ahead of the sprint.
  • Contact sprint organizers and let them know you plan to participate.
  • Read up on relevant issues in the issue queue.
Tester, Document Writer, helpers are some of the non-coders who can participate and help make a sprint successful.

Before the sprint

While the intensive work will wait for the face to face discussions at the sprint itself, preparation ahead of time will make the in person time much more focused and productive.


Creating a dedicated group is a useful way to organize the sprint and also share ideas and results. Discussion ahead of time can help define the need, existing solutions and initiatives, and some specific aims.


Why is this sprint needed? What specific problems are you addressing to solve? Focus on one key problem area helps a lot.

Existing solutions and initiatives

What existing initiatives are addressing the need you have identified? What are some of their merits and shortcomings?

Specific aims and intended outputs

What do you aim to produce? If the scope seems to large, try to refine it. Select a specific problem that may be representative of a larger problem set.

Draft an agenda

Always draft an agenda for each day of a sprint.

At the sprint:

This could be a sample sprint stages.


  • Introductions
  • Designate roles: recorder (one per day?) to take detailed notes throughout the day; facilitator, to facilitate as needed
  • Lightning talks: Each participant presents a 10 minute prepared talk on a topic relevant to the sprint aims.
  • Revise agenda
  • Confirm aims
  • Summary of current status of work
  • Identify main areas needing work, with a focus on components of an overall solution

After session, recorder revises minutes and posts to groups. Typically, this activity should be finished in an hour or two of the day one to focus on coding and implementation of tasks.

In depth

  • Taking components identified earlier, discuss each in detail, focusing on defining solutions.
  • Possibly, break into small groups (two or three per group) and delve into specific issues, reporting back to group.

After session, recorder revises minutes from day, posts to groups.

Plans and tasks

  • Define specific tasks
  • File issues outlining relevant tasks.
  • Potentially, break into small teams (pairs) and draft sample code.
    Break the work into concrete tasks with timelines and proposed implementation teams, including leaders and initial proposed membership.
  • Review broad solution components as identified earlier. To what extent do the concrete tasks fulfill this vision?
  • Assign short term work in documenting the sprint. Who will write up results? How will they be shared?


  • Go out for dinner or other social time
  • Make sure the work days aren’t too long. 8 hours is probably a good max unless it is a marathon, which generally is for the startups.

After the sprint

  • Write up and share results.
  • Start in to workplan.
  • Look for ways to stay engaged with each other.

I, personally, feel the culture of sprints is essential for a startup. It helps to identify issues and tasks and helps them to solve it quickly. Probably, that is the reason why Sprints form an integral part of an agile product development. I take this platform to urge and imbibe this culture from top to bottom in a startup and I can assure you if followed, one could promote an aggressive and wonderful work environment.

What do you feel? Share your views.

Leave a comment

Your email address will not be published. Required fields are marked *