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.

UI from Miro

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!