Scrummaker: the customer validation process
On Thursday and Friday October 4 and 5, Boost closed its doors for an all-hands two-day product development workshop, to build a new tool we call Scrummaker. This series of blog posts records the two days: what we made, and how we did in.
A little context: Boost is a team of designers, developers and Scrum Masters, who have been working with Agile for the past six years or so. As well as building websites and custom software and offering Scrum services and coaching from our Wellington office, we’ve recently opened an office in Shanghai offering Scrum training and coaching. Nathan Donaldson is Boost’s managing director and the Product Owner for Scrummaker.
As part of the whole Scrum ethos, I’m timeboxing the writing of each of these posts to 20 minutes, so if the brevity leaves you curious, feel free to get in touch for more detail.
Customer validation: the research process behind Scrummaker
Customer validation has been at the heart of this project. It’s actually seen us take a completely different direction to the one that, three short weeks ago, we thought we were moving in.
Originally, we’d considered building a tool to solve one of our own pain points: turning stories in Pivotal Tracker into physical objects for sprint planning and visible workspaces. At the moment, our Scrum Master or our Office Manager spend a not-insignificant amount of time each week pulling stories out of Pivotal Tracker as CSVs, dropping them into project templates in Pages, tidying them up, then printing and trimming. We’d identified this as a pain point and poor use of our time, and considered building a tool that would integrate with Pivotal Tracker and automate this as much as possible.
We used two frameworks to conduct and capture our customer research. One was Lean Launch Lab, a product that helps you store and visualise your customer research. The other was the Validation Canvas from Lean Startup Machine, a simple one-page format for displaying assumptions, hypotheses, and pivot points.
We conducted research in a number of different ways. The most complex was using unbounce to set up a landing page for our theoretical new product. We used LinkedIn advertising to promote the page, and tracked conversions from people visiting the page to following a call to action to sign up or find out more. We ran a poll through the LinkedIn Scrum Practitioners group, and we also conducted a series of email and face to face interviews with Scrum practitioners in Wellington and around the world.
What our customer research rapidly showed was that our ‘printing out stories is a pain in the ass’ sentiment wasn’t widely shared. (Perhaps, being a design-led company, we worry a tad too much about everything looking good as well as working well.) Instead, what emerged was a cluster of concerns around retrospectives:
- they aren’t always valued by teams and/or organisations
- they are hard to run with distributed teams
- it can be hard to generate actionable improvements
- it can be even harder to track whether these actions are taken and what the outcomes are.
Some market research showed us that few tools already exist to tackle these problems. At this point, we felt confident that we had a good problem to solve. What could we build that would help Scrum teams run efficient and valuable retrospectives?
Our next step – and the next post in the series – was to run an experience mapping workshop to generate a product backlog …