User Story Mapping: A Hackathon Game-Changer
Hackathons are intense events where teams of developers come together to create a product from scratch within a limited time frame.
Theyâre creative. Fun. But they are also stressful, especially when your goal is ambitious and time is precious. Landing a demo-able product at the end of a Hackathon can feel like driving a motorcycle off a ramp and through a flaming hula hoop while juggling three raspberry piâs. Nonetheless â when both tires hit the ground just so and the Zoom audience claps on Demo Day, itâs exhilarating.
It doesnât always have to feel so chaotic, though. At our last hackathon, my team â the DataDawgs â tried something different. We used a product development technique called User Story Mapping both in our planning and in our standups, and it helped us to stay focused, iterative, and deliver a great outcome. In addition to a successful demo, we ended up releasing a fully functional Datadog monitoring integration shortly after the Hackathon!
Whatâs User Story Mapping?
User Story Mapping is a product development technique that was first introduced by Jeff Patton, an Agile Coach and Product Consultant in 2008. It is a technique that helps teams visualize the user journey and identify the core features of the product. It involves breaking down the user journey into smaller, more manageable components called user stories. These user stories describe a specific task or goal that a user wants to achieve with the product.
Youâll end up with a map a little like the following, with three levels of organization:
Activity â what is the overall goal of the user at this phase in their journey?
Task (I prefer the phrase âStepsâ) â what are the linear steps to complete this activity?
Details or Sub-Tasks (I prefer thinking of these as âOptionsâ and âFeaturesâ) â what are the options for completing this task, and what additional features would accomplish the task even better?
Setting up the Story Map
At the beginning of the week, we started with a 1-pager on our customerâs needs for a Datadog monitoring feature, but this was intentionally barebones. Instead of trying to design everything upfront in a spec doc, this 1-pager contained just enough context to set the scene: the customers that asked for this feature, their words on their use case, and how other similar SaaS products have integrated with Datadog.
We then hit the (virtual) whiteboard software Miro in order to create our first version of a User Story Map.
Step 1: User Journeyâs Activities And Steps
To get started, we defined our anticipated user journey at a high level. We used Miroâs pre-built âUser Story Mapâ template, which comes with nice features like milestone cut-offs, and tags to mark in-progress and completed work.
We broke down the activities into steps like: âInstall integrationâ, âManage the Integrationâ, âUse Datadog for Monitoringâ. We then laid out the steps for each activity. We thought of this series of steps as a âbackboneâ of core steps weâd need to enable for this feature, but we didnât make decisions on what weâd develop to enable each step.
We ended up with an initial map like the following:
Step 2: Potential Options For Each Step
Now that we had our high level user journey, we discussed options to enable each step. A very practical example is that â when products build an integration with Datadog â Datadog provides two different authentication mechanisms: API Key and OAuth. We listed both options and moved on. Our goal was breadth and not decision-making at this stage.
As we went through this process, we realized that we missed activities and steps, or mischaracterized them. By iterating on this whiteboard together, we developed a rich vocabulary and shared understanding of the domain and project.
Step 3: Slice and Prioritize
With our list of tasks and options, we now had our first round of decision-making: what makes the cut for the Hackathon?
My colleague, Sankalp, identified both âneed-to-havesâ and âunknownsâ from the technical implementation side. I was able to suggest a small subset of Census datapoints to meet 80% of user monitoring requests, as well as âunknownsâ around how Datadog would actually interact with these datapoints.
As a result of these conversations, we made our best first guess on the MVP requirements for Hackathond demos, the MVP requirements for a broader customer release, and most importantly prioritized de-risking our biggest unknowns:
The technical âneed-to-havesâ early in the week with an unknown path to completion
Datadogâs exact product capabilities (neither of us were experts at the start), and how Census would need to structure data to maximize Datadogâs feature set
Step 4-N: Twice Daily Stand-ups For Tight Feedback Loops
We had our best hypotheses about the path to Datadog and Hackathon success, but notable Agile thought leader and boxer Mike Tyson had it right: âEveryone has a plan until they get punched in the mouth.â
Instead of shying away from new information that broke our assumptions (or gave us new options to enable a step), we welcomed this learning. We communicated on Slack regularly, but we also met twice a day for a quick Zoom call â at the beginning of the working day and in the mid-afternoon. This cadence gave us time to chat through our learnings and make changes to our plans, plus cheer on and recognize each otherâs progress!
Miroâs âUser Story Mapping Frameworkâ also had intuitive tagging features that we used to mark âIn Progressâ / âDoneâ / âBlockedâ work, especially helpful for us in the two weeks after the Hackathon â where we finished productionizing our work. We had an up-to-date corpus of the remaining tasks for an MVP launch to our customers, including what we had both pulled forward and punted from our initial plans.
Step N: Wrap Up And Demo!
With the time saved through careful planning and iteration, we focused on demonstrating the feature for real-life use cases. We prepared a pre-built dashboard of reports on reverse ETL data pipeline health, which not only enhanced our demo presentation but also provided immediate feedback for last-minute improvements.
Crucially, our demo proved the feature's worth for productionizing the week following the hackathon â a definite win!
Conclusion
By using User Story Mapping in a hackathon context, our team built a product that met user needs and expectations, prioritized high-value features, and managed scope to deliver a functional product within a tight time frame.
But more importantly, we enjoyed the process, and experienced less stress. And still made it through the flaming hula hoop.
P.S. Want to juggle some raspberry piâs, erm, I mean â work together?
Weâre hiring. Come say hi!