Note: This article is part of the How to win a Hackathon series.
When it comes to planning out a hackathon, I plan it almost exactly as I do any app (when I work in a situation where I’m allowed to that is).
What does it need to do?
I start by summarizing into a sentence or two, what the goal of the app is. This is your ‘elevator pitch’ and will help you stay focused as you transition from big picture to planning out the details.
Here are some sample use cases, the first three should probably be on everyone’s list:
- The visitor should immediately understand the goal of the site.
- The visitor should immediately get the impression that [example: the app’s goal is to help children reach their goals, or whatever your app’s goal is].
- The visitor should have one clear and immediate call to action they can take without thought.
- The visitor should be able to register.
- The visitor should be able to login.
Know your priorities
Once I have a list of what it will do, I put those in order from most important to least. In both a hackathon and in real life development, odds are you are going to run out of time with reaching the deadline. This priority list will probably change for a real life app, but for a hackathon and the shortened time frame, its a great recipe to stick to so you don’t have to stop and re-strategize mid-sprint to the finish. An important part of succeeding in a hackathon is the willingness to cut a feature. So many submitted apps have half-done features, or ones that were not well thought through and look hurried. Better to cut it all together and ship less, than to ship poor quality work. When it doubt, cut it, and knowing your priorities before hand can help you do this during a time crunch.
Detail the pages
To further understand the requirements of the app, I now list out every page that will be on the application, title it, describe it, and list out all the elements that will be on the page. This is great for not only ensuring you didn’t miss any tasks, but also for communicating design needs to your designer and front-end developer. I include what type of content needs to go on each page, though remember not to write any of the actual content until the hackathon begins. Also, note how the user gets to each page, and where they can go from each page. You can do this on the page notes, or even create a visual flowchart, that illustrates this.
Define tasks, roles, and milestones
Now that you know what has to be done, it’s time to break each feature or use case down into a list of what tasks are needed to create that feature, including creating the model, controller, database changes, views, design elements, etc. Then, I assign each one of these tasks to someone on the team, and note target milestones (deadlines) for each to be completed. This then helps you see if you have any chance of accomplishing your plan before the hackathon starts.
I like to group the tasks into “mini-sprints”. I find it much easier to focus on smaller groups of tasks, and its rewarding for the team when you reach each one and can hoot, holler, and high five in celebration to keep yourself on an emotional high throughout the long couple of days.
For both of our Rumbles, our first mini-sprint was the most important. We started at 9pm and the first sprint was to be completed by midnight. It was so important that I made up a music playlist just for that first sprint. Our goal for this time was to have the following completed by midnight:
- Linode server setup
- Git repo setup
- Deploy script created and tested
- Rails framework created, checked in and deployed
- Gems installed and deployed
- All models, controllers and views stubbed, checked in and deployed.
With this completed after the first 3 hours, we knew there would be no infrastructure surprises to haunt us in the end and we could focus on making the app awesome right up until the last minute.
For PeepNote, we had 11 development milestones and 6 designer milestones. We completed all 17. There was an optional list in case we had extra time, but we didn’t get to much on that list.
Plan to Fail
Another important part of the plan is to plan your failure points. Make a list of all the failure points and risks, both with building your app (the biggest challenges) and within the app (exception handling).
Some of your tasks may be technological “risks” and if you aren’t prepared they could derail the entire plan. For example, pulling a list of friends from Twitter, if you haven’t done it before, and working with the Twitter API would be a risk.
Poorly handled exceptions within the app could jeopardize your impression with the judges and voters, so itemizing these and planning ahead on how to handle them will save you time and ensure you are prepared.
Quality and Completeness
It’s more important to have a good quality app and one that is complete in what it promises than a bunch of almost finished features.
Cut features mercilessly as you near the final stretch, opting for quality over depth. If you promise it on the home page, it should be there and work completely. Otherwise, don’t mention it.
With a detailed plan in hand, and understood across the team (again, this is part of the communication I discussed earlier), your team will be prepared to hit the ground running and won’t need to spend valuable building time with planning and strategizing, which can be particularly challenging when you are tired and emotionally drained.