Use Scrum to Improve Your Hackathon Performance
Scrum events will bring the structure that you have been missing to your hackathon
Scrum is a lightweight approach to help generate value through adaptive solutions for complex problems. Scrum is widely used in the software industry to develop software iteratively so as to generate value at every increment.
A hackathon is a short sprint (typically 36–48 hours) to create a functioning product by the end of the event that solves the problem defined by the organizer of the hackathon. Hackathons are focused on one product goal where a team with diverse skillsets comes together to create the end product.
Quick Note — This approach modifies the traditional Scrum framework to fit a very particular need. There isn’t a dedicated Product Owner or a Scrum Master because typically a hackathon team is capped at 6 members and you would need everyone on the team to be able to contribute as a development team member.
Use Scrum Events to give more structure to the blur of time
A hackathon without a set structure just feels like a blur of time where you are fumbling to get something together to be able to present at the end of the 36–48 hours. In most cases, you will have an end product but you don’t have a replicable method of getting you to a similar outcome every time.
Breaking up your hackathon into shorter timeframes to create mini-sprints will help provide more structure to the event and provide you and your team with a clear understanding of the work performed and work that is still pending. For a 36–48 hour hackathon, you should be able to squeeze in about 3–5 sprints.
Kickoff your hackathon with a sprint planning event to identify the goal for the next few hours of work and to break it up into user stories that the team can start working on. Writing out user stories with clear acceptance criteria will ensure everyone is on the same page regarding the output of the story.
Next, check-in every few hours (every 2–3 hours) as a team to update the rest of the team on your progress and highlight any impediments you are facing. If you need to discuss something with someone, this isn’t the place for it so get in touch with them as problems arise. This stand-up shouldn’t go on for more than 15 minutes.
Based on how long you determined your sprint is going to be (6–8 hours is what I would recommend), you will delve into review and retrospective towards the end of the sprint. The review is the place for each team member to showcase the progress they have made so far to achieve the sprint goal. Everyone on your team should have completed the user stories assigned to them that support the sprint goal but if this is your first sprint being pretty close to done should count for something!
Once everyone has demoed their work, as a team you will participate in a retrospective to discuss what went well, what didn’t go well, and any problems that were encountered that are/aren’t solved. The retrospective is really important to improve the team’s performance as you are getting closer to the hackathon deadline.
Next up, planning again based on the review of progress. A new sprint goal is determined that brings you even closer to the product goal. This cycle of sprint planning, stand-ups, review, and retrospective will continue until you reach the end of your hackathon.
Last but more importantly, if you are going to be diving into more hackathons, participate in a retrospective going over the entire experience of the hackathon. It doesn’t matter if you aren’t going to be able to work with the same team again, but it’s important for you to learn where you and your team fell short this time around to help you in the future.
Why are these scrum events important?
Planning — helps everyone get on the same page about the work to be done and clearly define what is considered done. This is extremely important because you can’t really afford errors on such a quick turnaround. This should take about 30 minutes to an hour.
Stand-ups/Check-ins — helps everyone collaborate and gives the team members a space to raise any red flags and issues that they are facing so you can either fix them or find a workaround. This will take less than 15 minutes.
Reviews — to actually be able to see the product coming together. Reviews encourage team members and keep them motivated throughout the hackathon as they are able to show and see a working product. Reviews also highlight if you have missed something so that you can course-correct during the next sprint. Reviews should be no longer than 20 minutes.
Retrospectives — helps understand how you are working together as a team and if there are problems members are facing, then the team can come together to solve them during the next sprint. Retrospectives should be no longer than 30 minutes.
How will the scrum artifacts help?
Product goal — this helps the team get on the same page about the problem statement and the solution the team is proposing. If the theme of the hackathon wasn’t revealed earlier, the team might have to spend a few minutes upfront to clearly state the problem statement and then brainstorm solution ideas.
Sprint goal — helps identify the functional increment you will be working on during the sprint. This helps the team work together on a single objective instead of different initiatives.
Increment — an iterative functional product that works. Each increment is cumulative to the prior increment so it should be tested each sprint to ensure there are no surprises at the end.
TL;DR
One can’t afford mistakes during hackathons since the timeframe is so limited. The Scrum framework brings in the transparency that the team needs to ensure there are no gaps and everyone is crystal clear on the end goal. Use the sprint planning to set objectives, stand-ups to flag any issues and provide updates on your progress, review to demo the work you have done, and most importantly retrospectives to focus on continuous improvement and provoke change so you can get better!
