Scrummaker: The experience mapping workshop

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 to support teams to run Agile retrospectives, which 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.

The experience-mapping workshop

Since we started using story mapping last year, we’ve made experience mapping a regular part of all new project kick-offs. It’s the best way we’ve found to quickly generate and prioritise a product backlog.

For Scrummaker, our experience mapping workshop was made up of three of Boost’s Scrum Masters plus two other prominent Wellington Scrum practitioners. Nathan facilitated the session, in which the group

Brainstormed all the steps in running a retrospective, from starting thinking about planning a new retro through to checking back on progress on actions from a retro held several weeks ago

Wrote each step on a post-it note, then put these in a long single line along a wall, from start to finish

Grouped the post-its into the major steps for planning, running and reviewing a retro, and identified pain points in the process, which included:

planning effective retros

running good retros with distributed teams

collecting information from a retro and sharing it with the team

Reviewed these pain points to identify where a product might lie.

The group then did some rapid persona development: a quick exercise to identify different users, the context each is operating in, and what they value. (This kind of persona development is described by Jeff Patton in this 2009 talk on pragmatic personas.) These personas were then prioritised, with Daphne the Distributed Scrum Master coming out on top.

Daphne, our key user persona for Scrummaker

Daphne’s context

Daphne will use Scrummaker to run online retros

About Daphne

She is an experienced Scrum Master with a distributed team (a team split over several locations that finds it hard or impossible to physically meet)

She has had trouble getting value from the retros she runs with these distributed teams

She feels out of sync with her team

She finds it hard to follow up on retro actions

Daphne values

Being able to see her team during the retro

Easy coordination of meetings across time zones

Good team communications

Tools that are easy to set up for the team

Good visibility of actions

Integration with other tools e.g. Pivotal tracker, Basecamp, Jira.

(Our other two personas were Rob the Rookie, an inexperienced Scrum Master who has just passed the CSM and is working on his first project, and Carl the Corporate Scrum Master, who is a more experienced Scrum Master with particular concerns around traceability and accountability for retro actions and outcomes, and data security.)

Taking the retro steps they had identified, the group then wrote features for the tool based on these personas. Finally, using Daphne as their priority customer, the group arranged these features into three releases: the minimal viable product (MVP) and two further releases that would add more and more value.

And that was the end of the experience mapping workshop. Between the time that we ran the workshop (Tuesday) and the morning we met to start work on the new product (Thursday) Nathan worked with Federico, one of our Rails devs, to turn the features on the post-it notes into fully developed user stories with complete acceptance criteria, so a product backlog was available for the team on Day One.

There was one more step between the experience mapping workshop and project kick-off. The team decided to hold a technical Q&A session, to thrash out some details so we could hit the ground running on Thursday. The next post in this series covers this technical discussion.