How to run a brilliant contribution sprint, brought to you by Open Strategy Partners.
Are you planning an open community source event? You might be thinking of adding a code (or documentation or marketing!) sprint, contribution night, or hackathon to your event to foster contribution and get some work done while you have a critical mass of people together.
First and foremost: Thank you for your contribution to your open source community! Thank you for making sprints a part of it! This is our guide to help you run a productive and fun event.
At Open Strategy Partners, among the open source communities and organizations we’ve been involved in over the years, we’ve been to a lot of events. We’ve contributed, coded, hacked, for thousands of hours at countless sprints. Just like we say about our open source code, you shouldn’t have to reinvent the wheel every time we run a sprint. We’ve boiled our experience down here, done research, and taken guidance from the wisdom of others–"building on the shoulders of giants"–on running a great … brilliant! … sprint.
Don’t feel that you can’t run a code sprint if you can’t cover every single point in this guide. If you get power, WiFi, food and drink, and sprinters there, you’ve already got the potential for a great sprint. As you plan and look through this guide, do as much as you can manage for your sprint. When it’s done, take note of what went well and what didn’t go so well–and iterate! Do a little better next time!
Contribute to this guide - We’d also like to know what went well for you and what we’ve forgotten or gotten wrong in your view … and that’s why this guide itself it open source and ready and waiting for your input on GitHub. Make one more contribution and help open source communities sprint better!
"Code sprint (n) 1. A sprint is a time-boxed period of software development focused on a given list of goals." via Effective Code Sprinting
Contribution sprints are part of the lifeblood of open source software projects. They are a good way to hammer out problems, squash bugs, and clean out a backlog of issues. Sprints attached to larger events can draw in new people and set up community members for a lifetime of contribution. Stand-alone sprint events offer the time to work together free of distractions, booth duty, or sessions. We’re using the term contribution sprint throughout this guide (rather than "code sprint", for example) because open source projects need much more than code to thrive and valuable contribution comes in many forms: code, documentation, marketing, event organization, legal advice, and much more.
What does it take to make a brilliant sprint? How can you set it up to be repeatable? We’ve broken down this guide into seven sections. We hope this guide will get you thinking about the kind of event you want to run and then give you enough practical, actionable advice to make that a reality.
-
Three contribution sprint essentials: Three top priorities for an event to facilitate open source collaboration.
-
Why: Your purpose; working towards software, project, product, or community development goals; welcoming new people and establishing or extending relationships that will continue long after the sprint. Keep your goals in focus. This is a social event; it’s all about the people.
-
Who: Attend to the expectations people have for the event, and which you have of them. Build a team. This includes volunteers, mentors, project leads, participants, newcomers, teams.
-
What: The goal of the sprint; issues you work on; or the tasks people tackle. Plan activities taking into account how people will find things to work on.
-
Where: The venue, the accommodation, seating, logistics, furniture, flipcharts, and virtual spaces. Consider how your space facilitates collaboration.
-
Your sprint team box: Get a nice big box; you’re going to start gathering up all the tools you need for the day. You need more than just "Powerstrips, extension cords, lots of coffee." Print this as a final checklist of everything you need to ensure success on the day.
-
When: Plan backward from your event and delegate as much to your volunteer team as possible. Timelines for planning, scheduling, external communications about the event, internal communications with the team, recruitment of participants, as well as what happens on the day.
Sign up to our newsletter to get updates on the Sprint Kit.
For this guide, we assume you’re taking care of general event logistics and covering the essentials of running a brilliant sprint. Here are three top priorities necessary for an event to facilitate open source collaboration.
1. Accessibility and getting there - You want to be able to get people to your event easily. The more people you can support getting there, the stronger and more diverse your community (and your contribution sprint) will be. All of the general event best practices apply to contribution sprints, such as providing information about transportation, accommodation, parking, and most importantly, accessibility. Go out of your way to make the needs of contributors with different abilities and needs a top priority when choosing a venue and making your plans. Their contributions will make your software better and make make it easier for more people to participate and benefit from it in future.
Eventbrite’s 10 Ways To Make Your Events More Accessible For Disabled Attendees gives good advice on the how and why of accessibility at events.
2. Safety and security - Laptops being stolen or people endangered at an event are the last things anyone wants. Ensure your participants are safe and that they know know they are safe. Assign a lead volunteer to be in charge of security and safety.
Prepare for the worst case scenario and develop an Emergency Plan. Depending on what your venue provides you may or may not need insurance to cover potential issues. Depending on the laws in your country or region you have responsibilities for the health and safety of your event attendees. Check with your local authorities and your venue. Regional example: The UK Health and Safety Executive gives this advice on event safety.
Tip: Remind people to watch their valuables. Attendees bring expensive computers and equipment to tech events. They should not leave valuables alone, even "just for a minute." You may be in the midst of your lovely, generous, open source community, but not giving anyone–and you don’t know who has access to your venue–opportunities like these is the easiest way to prevent theft. Don’t give them one.
3. Guidelines around collaboration, behavior, and etiquette - Your open source project should have clear contribution guidelines and coding standards. Just starting out? You can follow this OpenSource.com template for creating open source contributor guidelines or have a look at GutHub’s standard for contributor guidelines. Your guidelines should clearly reflect the norms of collaboration and accountability in your project.
Tip: For more ideas, check out the "Collective Code Construction Contract", which is an extension of the Git collaboration ideas behind GitHub Flow. These are good examples to follow, whether you use Git or not.
Does your community already have a code of conduct for events? If not, now is the time to provide one. Check out Ashe Dryden’s Code of Conduct 101 + FAQ.
"The in-person code sprints at community events do produce new patches, but I contend their primary purpose is to create and strengthen the interpersonal relationships that make our otherwise remote collaboration on the project so successful." - Jeffrey A. "jam" McGuire, Open Strategy Partners
Contribution sprints are a core activity and a sign of a healthy open source software community. They are as much about the community, as they are the code. The in-person interactions, cracking tough problems together face-to-face, laughing, struggling, and getting work done together create the relationships that make productive, respectful, online collaboration the rest of the year possible. Sprints are where a lot of code, a little bit of magic, and "community glue" happen.
There’s no question that success in some part will be evaluated by participants according to the volume of issues closed or work completed. But the longest lasting effects and outcomes will be determined by how people feel about the event. You want project leaders to be supported in their efforts. You want newcomers to feel welcomed, have success experiences, and be prepared for a career of contribution. You want participants to keep coming back and become volunteers and community leaders in the future.
Think about your own "why" for the sprint. Make that clear in your communications. Talk about the work, but also talk about the goals and the vision and the people who can make that all happen.
Don’t wait until after the event to prepare post-event communications. Gather statistics and stories as you go. Report back and celebrate contributions and discoveries as a volunteer team. If you plan the celebration blog post beforehand, you can take notes throughout the day to fill in specifics. What stats are you reporting on?
-
New maintainers? First commits? Great stories?
-
Number of attendees
-
Number of issues closed/open
-
New issues added
-
Number of new contributors
Don’t forget that while the sprint is a time-boxed event, you want the results to be long-lasting. Working together is a social activity, and a code sprint is a social event. Because of this, social bonding is as important as completing each task. The tasks serve to focus collaboration, but the primary purpose is to help forge good working relationships for the future. The time people spend socialising is a chance to reinforce the friendships. Plan for time where people are taking breaks together. If you have many people coming from out of town, can you arrange a tour? A meal together away from the venue?
Tip: Celebrate contribution as you go. At DrupalCon contribution sprints, there is a ceremony for someone’s first patch being committed to Drupal core. Check out Jeffrey A. "jam" McGuire’s Acquia Podcast episode *137: First patch! Matt Moen, DrupalCon Austin, and a village of contributor*s. From the podcast post: "... a patch written by Matt Moen, Technical Director at Kilpatrick Design, was selected for fast-track testing, approval, and was committed to Drupal 8 core in front of a few hundred of us at the Austin convention center. … The First-Patch "ritual" is a celebration of what we do in Drupal and open source software (check out the energy in the room in the 2nd video!). Remote collaboration can feel abstract and lonely. By highlighting one patch, its creator, and all those who got it ready for approval and inclusion in the Drupal codebase, the community has a concrete moment to focus on when it is "really real" and happening right in front of you.
Prepare a communications plan for promoting the event. Ask mentors, project leads, volunteers to blog about the sprint and share on social media. Make it easier for them by writing short descriptions of the event, short memorable URLs, and hashtags to use.
You want people to sign up in advance, not only to gauge interest, but also for resource planning. If you’re sprint is by invitation only, this won’t be as much of an issue, but it really helps to use a ticketing or sign up system for people to express their interest. If you use a signup system, you can:
-
Better plan food, refreshments, and spaces.
-
Keep in contact and send requests and reminders to people who signed up.
-
Increase the buzz around your event.
With a list of registered attendees, you’ll have a pool of people to draw on for volunteers, too. In the future, you can thank them for attending and invite them to get involved in your next event.
By considering all of the aspects of running a sprint that we touch on in this guide, you’ll be well on your way to ensuring that your sprint is a success for you, your participants, and your community.
Be clear with your volunteer and organizing teams about the roles and responsibilities involved in ensuring you have a fun, productive sprint. Take time early on to define the roles you need and what your expectations are. In your communications, be clear about who is handling what, and how people can contact those individuals. Also consider the types of participants you have, what they expect, and what you expect of them.
Here are some typical sprint team roles:
-
Event and Sprint Leads - in charge of the overall event
-
Main points of contact for the event
-
Leads should delegate tasks. Work with your volunteer team, teach them, and delegate as much as you can. This approach will also set up these volunteers to lead successful sprints in the future.
-
See the section of this guide When? Planning timelines for your brilliant code sprint.
-
-
Project Leads - in charge of specific contribution areas or projects
-
Adjudicate decisions at the sprint.
-
Points-of-contact for their initiative, project, or area.
-
If you are planning a multi-day sprint, project leads should consider scheduling specific dates and times for focused, time-boxed collaboration within the larger event.
-
-
Mentors - reliable help for newcomers
-
Welcome, orient, and help sprinters, whether first-timers or old hands. They need an overview of what is going on at the sprint.
-
Need the compassion and kindness to answer the same questions over and over.
-
How many mentors do you need? Drupal.org’s guide for core mentoring recommends one mentor for every eight participants.
-
If your sprint is focused on Drupal 7, Drupal 8, TYPO3 CMS, Backdrop CMS, or Wordpress, with DDEV-Local you can get local instances of your CMS up and working on participants’ MacOS, Linux, and Windows computers in minutes.
-
-
Participants - the folks who will come in to contribute and collaborate
-
How many participants can the venue hold? How many can you afford to accommodate and feed and caffeinate?
-
Considering who you need at the sprint, and who you’d like to attract can help you focus your promotion and recruitment efforts.
-
-
Newcomers - first time sprinters and contributors!
-
If you have sprint registration and mentors, ask participants about their experience level to help sort and prepare them for contribution.
-
At code sprints, help them get their local development environment set up.
-
-
Teams or groups
-
Pairing up or working in small teams is ideal at sprints. Make it possible for people to self-organize, identify each other, and contribute in areas where they’re interested and knowledgeable.
-
Label tables or parts of the room for specific groups.
-
Provide groups with flip charts, if available.
-
Groups can communicate and plan before the event to get the most out of working together in person.
-
Ask your mentors and leads to prepare an orientation guide for people as they come in. Where are the toilets, emergency exits, snacks and coffee, and other facilities? Who and where are the project leads? How can people find out where to jump in? Who is there to help? Assign volunteers to be responsible for welcoming people as they arrive, setting up their local development environment, and getting them productive as quickly as possible.
If you can run this orientation in the morning as a group, that’s great. If your sprint is running alongside or as part of another event such as a camp or conference, it’s likely you’ll get ad-hoc drop-ins. You’ll need to welcome and orient them, too.
The Open Source Bridge wiki suggests organizing the day in short iterations, such as 45 mins. You could also repeat welcome sessions around meals and social break times. Use these to remind people of the essentials (ground rules, emergency exits, etc.) and to help new arrivals get their tools set up, find the right task or project, and so on.
Tip: Keep a numbered sign-in sheet as people come in to help track how many attendees you’ve had during the sprint. Open source communities and event attendees love statistics and numbers. Tracking attendee numbers, patches, contributions, cups of coffee consumed, and so on makes for great sharing on social media and can be a great source of motivation for your community.
Make sure your sprint is successful with careful planning ahead of time. As part of preparations, project leads will need to "triage" and prepare issue queues and identify what they want to work on in the sprint. Useful triage includes:
-
Tagging issues with your sprint name to make them easier to find.
-
Tagging issues for newcomers, or whichever term is appropriate for your community.
-
Reserving easier, newcomer-appropriate issues for sprint newcomers ahead of time.
As the day progresses, keep track of the issue numbers you’re working on. Track if they are assigned, who is working on them, and if they are done. Your issue queue might manage this, but you could also set up a Google Spreadsheet or post-its, or a whiteboard. Mark off issues as they are completed.
Set up a page in your community’s site or in documentation for the sprint. Make a shortened URL for easy reference and sharing. As you promote the event, keep this canonical link up to date.
Helping new contributors get set up makes a huge impact - Researchers have found that the biggest barrier to open source code contribution is getting a local environment set up. Newcomers who spend a long time getting set up find it frustrating and demotivating. We’re helping sprint organizers resolve that with DDEV-Local, which provides a repeatable, quick and easy-to-install development environment. Check out how to install DDEV and install the CMS of your choice (currently Drupal 7, Drupal 8, TYPO3 CMS, Backdrop CMS, and Wordpress) and please sign up for our newsletter to keep up-to-date with the latest developments around DDEV.
Show them where they can help - When preparing for your sprint, project leads should collect issues that need addressing for each project. To make it easier for people to find places they can share their expertise and enthusiasm, one recommendation is to group the issues by type of work, or expertise needed. Mozilla’s advice for newcomers on participation basics recommends that new people should "find a project you’re interested in." How are your participants going to do that? See how Mozilla’s Global Sprint Days are organised by project for some ideas.
Learning-by-doing - One popular idea is to prepare sprint tasks specifically for newcomers. The idea is that you reserve appropriate issues in the time leading up to the event. These types of issues will give contributors experience with whatever workflow you’re using, while taking care of tasks that are relatively quick to resolve. Tag the issues with tags such as "first-timers-only," “good first bug,” or “Novice tasks.”
Tip: Helping newcomers commit changes to your project gives them a success experience in your community and increases the likelihood they will come back for more. Furthermore, ownership and effort increase the perceived value of concepts, things, and projects to us. The feeling of knowing code you’ve checked, written, or influenced is being downloaded (tens or hundreds of) thousands of times a month can be a huge motivator.
Provide mentors - Make sure you have mentors who are prepared to help others and answer the same question 100 times with kindness and compassion. They should be easily recognizable, having a special t-shirt or a badge can help.
"The primary requirement for a sprint is to provide a working environment." - Art of Community, Jono Bacon
When everything works at a venue, no one seems to notice. When something basic goes wrong, it’s all people can remember. Bad wifi? Too hot? Too cold? No coffee? Not wheelchair accessible? Weird table configuration? Not enough flip charts? Boom! Disaster.
Different room configurations facilitate different styles of working and affect how many people can be productive in a room. Round tables, or classroom style seating around rectangular tables are better suited to contribution sprints with many smaller groups, than U-shaped meeting rooms, which can be good for larger meetings. When assessing a venue, check where the power outlets are and how you can safely get power to each table or group. Think about how your space can facilitate collaboration and concentration.
This fantastic report from Drupal Dev Days 2014 touches on details about their sprint venue, connectivity provisions, and accommodations. For example, in addition to sprint rooms, they also provided a "silent" room and a few small rooms for meetings. This means you can facilitate discussion, while providing quiet spaces where people can concentrate.
No one works well thirsty and on an empty stomach. Food and refreshments are important. You should seek sponsorship for feeding and watering your sprinters. People are volunteering their time to contribute, the least you can do is provide food and drinks … and coffee. Lots of coffee.
Where can they find coffee or food nearby? Plot these places on a map. An on-site café or nearby coffee cart means people can buy refreshments outside of the scheduled meal and break times. Some venues don’t allow you to bring in outside catering; make sure you understand the requirements of your venue.
If you’re hosting the sprint, you have to be prepared to receive guests from out of town. In some cases, a central location in a major city is handy for travel. However, you might be able to find a hotel or hostel in a smaller city or remote location to host the event in its entirety. That is how the TYPO3 CMS community runs many of its contribution sprints and events. The advantage is that you can accommodate attendees so they can work together at all hours, socialize together, all staying in the same location together. Because the events are in smaller cities, the running costs are kept relatively low, too.
Where are people meeting after the event? Plan specific group meals and/or social activities (out of the venue). The social interaction away from screens and keyboards is an essential part of building community. The in-person relationships help the remote collaboration that makes up most of the rest of the year.
Due to disabilities, time constraints, or travel costs, people can’t always attend all the events they want to in person. In this guide, we’re focusing on sprints run in-person and on-site, but you should facilitate remote participation, too. Any tools that facilitate remote participation and contribution also help those there in the room. An active IRC or Slack channel lets people discuss issues in silent rooms with a team of collaborators.
To support virtual collaboration you need a space online. It’s likely your community has a place such as IRC or Slack. Slack has become popular because it’s easier to use than IRC. However busy open source communities soon reach the limitation of the "free" levels. This means the back scroll is not accessible or searchable. The costs for making Slack teams accessible is exorbitant and charges increase as you grow, which penalizes you for being awesome.
There are viable open source alternatives to Slack, like Mattermost or Riot. If you can’t run your own server, consider Gitter or Spectrum. Good news is that Gitter or Spectrum (free tier) conversations are open and searchable. With Gitter’s GitHub or GitLab integrations you can comment on issues, and search them. See the Rails channel "activity feed" as an example.
Start preparing your project plan to prioritize what needs to happen when. How much time do you have to plan your sprint? What needs to get done? Build your preparation timeline and checklist working backwards from the event date. Start with the list below, compare it with available resources like Mozilla Sprint Planning Sheet Google Sheet, and customize according to your specific situation and needs. This kind of planning checklist is to help you handle all of the details in a timely way without getting overwhelmed.
Tip: If your sprint is part of a larger event, you’ll need to coordinate all of your planning and communications with the main event. Your team should be part of the overall event team or working hand-in-hand with it. Watch out for assumptions of who is responsible for what. Make sure that you know exactly what you get by being part of the larger event (perhaps catering, WiFi, venue contracts, etc.) and what you are responsible for (e.g. your volunteer team, power strips, extension cords, sprint signage).
Tip: Use a dedicated project management tool to manage tasks. The Drupal Ireland community has used Trello, for example, to create and assign tasks. As you read through the list below, keep in mind that as a leader, you should be overseeing work and delegating as much as possible to your team of volunteers. Delegating gives others investment and ownership and prepares the way for future community leaders to take over next time.
Two+ months before
-
Visit the venue: Take photos. Start planning what signage you’ll need. How many power outlets are there? Start thinking about room layouts, quiet areas, break locations, and so on.
-
Budgeting! Determine the costs to set a target for fundraising. Check with the venue: What’s included? What insurance is provided? Do you need to pay a deposit? Is there a minimum charge for catering, coffee and tea, or other amenities? What equipment do you need? How many people can you host?
-
Connectivity. Based on your venue and the estimated number of connections, find out what kind of connectivity you need. While venue WiFi continues to improve over the years, explaining to non-technical people just how much bandwidth a few rooms of open source community contributors working hard will consume can be a bit if an art.
- David Rodríguez of the Drupal Developer Days 2017 team prepared a report about how they provided network access to 250 people.
-
Sponsorship packages. Prepare sponsorship packages to reach your fundraising goals.
-
Prepare a Sprint page - even if it’s a stub. Get the short, memorable URL for reference and promotion.
-
Communications. How are you promoting the sprint? What are your community’s channels and social media watering holes? What other tech communities might be interested in attending your event, too?
-
Recruit sprint mentors, project leads, and other volunteers. Expect you should line up more volunteers than you think you need. Stuff happens!
-
Prepare the event map. Where are amenities close by? Prepare travel advice, directions, parking information. This is an easy job to delegate to a new volunteer.
Six weeks before
-
Sponsors. Are they sending anything for the event such as swag, gifts, pop-up banners, etc? Make sure you get them on time.
-
Prepare your Emergency Plan. The venue may be able to help you. Gather the numbers of the fire department, police department, and hospital details.
-
Plan and prep communications around participant recruitment.
-
Promote the event to participants. Who can share your messages? Such as local colleges, coding communities, your local OSS community, etc.
-
Social media sharing. Schedule and automate social media sharing and sponsorship thank-yous with a tool like Buffer. See the section of this guide on Communications before the event.
Two weeks before
-
Check with the venue, bring volunteers on a tour of the venue if they are not familiar with it. Take photos of the venue if you didn’t on your first visit. Plan the signage you will need.
-
Issue queue triage. Project team leads should work on this.
-
Volunteer schedule. When are people available? Who can cover?
-
Who is participating? The Drupal community recommends a sprint sign-up sheet (google doc template)
-
Final communications around the event. Confirm attendance of key participants. Ask them to share on social media to build buzz. Write a blog post referring to key resources.
Tip: Kristen Pol’s blog about prepping for sprints at DrupalCon Austin contains excellent ideas and details on this.
One week before
-
Continue to promote the event. Who is sponsoring? What will you be working on?
-
Plan post-event communications. Include stats you plan to track during the sprint.
-
Print check-in sheets
-
Print /draw signage, including
-
Wifi code
-
Hashtag / Channel info
-
Contact info of people in charge
-
Link to the Sprint event page
-
Giant arrows you can label and put up on the fly to help direct attendees
-
-
Gather contact information for volunteers.
Day before
-
Check your checklist and your sprint team box.
-
Get good sleep!
-
Check in with all of the sprint volunteers.
-
Test network access
-
Check with catering
Morning of the event
-
Grab your sprint team box and go!
-
When you arrive at the venue check if any of the essential details have changed from when you printed your signage. In case they have, you can write correction and additions on the whiteboards or flipcharts when you get in:
-
Wifi code
-
Hashtag / Channel info
-
Contact info of people in charge
-
Link to the Sprint event page
-
After
-
Follow up on post-event communications quickly.
-
Thank you notes to sponsors. They appreciate handwritten notes and cards.
-
Blog post thanking participants and sponsors; include photos from the sprint, stats about achievements from contributions made, to numbers of attendees, to cups of coffee consumed and more.
- Include a newsletter or similar signup for future events
-
Social media
-
Thank you’s to all sponsors
-
Stats from the sprint
-
Call for signups for future events
-
If you’re running your sprint as part of of alongside another event, it’s likely you’ll get a rush of attendees at the start of the sprint, and after event breaks. You should plan on managing drop-ins. See the section of this guide: Prepare (and repeat) a welcome orientation.
Another idea to encourage breaks is to break up the day into shorter sprints. Depending on the size and length of your code sprint you may way to allow Project Leads to schedule specific times or dates to work on their projects during the overall sprint to better time-box collaboration.
Make sure it’s clear at any point who is available to help. Your sprint volunteers may act as runners or butterflies, handling issues as they come up. Make sure you have all your volunteers’ contact information and the permission to share it with sprinters. Twitter group DMs, a WhatsApp group, or similar solutions can help with group communications.
Tip: Sprint team uniform. Sprints leads and volunteers at many events wear a special coloured t-shirt to make it easier for participants to spot volunteers who were there to help. If you’re printing up event t-shirts in any case, most vendors will print enough for your sprint volunteers on different coloured fabric at minimal additional cost.
Get a big container and start adding supplies to your Sprint Team Box as soon as you begin event planning.
-
A clipboard to organize your paperwork for the day
-
Your customized checklist for what is in the box and what you need to do.
-
Contact information for sprint volunteers, catering company, venue representative.
-
Contact numbers of the fire department, police department, and address of the nearest hospital. Contact information for volunteers in charge of safety.
-
-
Printed materials you need, including
-
Numbered sign-in sheets. (Why? If it’s 1-50 on each page, you can more easily count drop-in participants and report back.)
-
Signage. Print out signs separate from HUGE arrows. Why? Because you may not know til the day which way they should point!
-
Crowd Notice Photo Release poster. Example photo release poster. This notifies people that if they don’t want to be filmed or photographed, they should avoid that area. Check your local laws around photographing people for non-commercial use. These laws may differ if children are present at your event.
-
-
Supplies
-
Whiteboard markers. Whiteboard wipes or whiteboard eraser.
-
Post-it notes.
-
Boxes of pens.
-
Powerstrips. Labeled with your name on them if you want them back.
-
Extension cords as needed.
-
Tape to safely secure power cords running through your sprint areas.
-
Power adapters for people coming from different countries. Labeled with your name on them if you want them back.
-
Presentation adapters. Labeled with your name on them if you want them back.
-
If you’re in a larger room, a digital projector and a mic help.
-
Tape, you always need more tape. Gaffer tape, masking tape. Blutack.
-
Paper towels.
-
First aid kit.
-
Tip: If you prep this box six weeks in advance, someone is going to "borrow" the tape, or whiteboard markers, or something else ... Come back and check the box a day or two before your sprint and make sure you have absolutely everything you need.
Have any feedback? Come and check out this Sprint Guide in GitHub, we’d love your feedback.