From User Research to Product Backlog - First Experience with Design Thinking and Lean

Some months ago, I had the challenge to guide a team from complete ignorance of the product domain towards a backlog and a first release after barely three months - luckily, they were very smart and eager to learn...

So we also heard of design thinking and how it has been successfully applied to grasp the customers' need and desire across different industries, including software (see Tim Brown's blog, for instance). Hence, we engaged an experienced coach for the team and started user research to better understand the domain and the problems at hand. We even spent a full week at a major event, observed, conducted interviews, and exchanged our experience within the team.

Based on that first-hand experience, we conducted a 3-day workshop after the event (see agenda poster in the picture): On day 1, we brough all our experience together in the form of a "storytelling session", so that everybody in the team is on the same page. Due to the plethora of data points and observations, we had to cluster and select certain topics to focus on. In particular, we focussed on two major personas as assumed future users of our software. We created their profiles and wrote down what motivates them, what they liked and what they don't like about their daily business. Still on day 1, we also created an initial product vision in the form of a fictitious product box (lead by the product owner as moderator) and gathered the first low-fidelity paper prototypes for possible features (entire team)... On day 2, we took on these results (personas, vision, and features) and started building up the product backlog in the form of a story map (see Jeff Patton's homepage). In this two-dimensional map (priority on the vertical and usage sequence from customers' perspective on the horizontal axis) we collected and arranged the first set of user stories (see Mike Cohn's contributions for Mountain Goat Software). At this point, the whole team was capable and motivated to describe the requirements from the formerly unknown domain from a user perspective, i.e. in the form of user stories along a typical usage sequence. On day 3, we decided on which agile process framework to use (Scrum) and the team's detailed working model (sprint length, done criteria, tooling, etc.).

On day 4 we started working... (to be continued)