A few days ago, I attended a user researcher meet up session organised by the Register of Scotland. It was interesting to hear panel member’s experiences including dos & don’ts, insights, empathy, stories and of course free Jaffa cakes. This was an after-work meetup event and their interesting stories made me forget about my rumbling stomach.

During the question and answer session, it became very obvious that almost everyone in the room was involved in some kind of discovery phase. For readers who are new to the term “Discovery” – it is the time before you start building a service when you find out whether users need it and whether other services exist. This part of your project is called the discovery phase. (Read more about Discovery phase).

They were all facing a similar kind of challenge, convincing people that user research is a very important aspect of service design. And it needs to happen before you design any service or build any system or product. Then I heard someone mentioned that they are trying to fit the activities in a 2 weeks sprint cycle and are always under pressure to feed user stories or customer insight to the product owner to keep the story-hungry scrum team going.

Our experience:

We had a similar situation in a current project where the discovery phase was completed elsewhere, and our organisation was partnered to deliver an ecosystem which other similar government organisations can use. This was the alpha phase to build a prototype and prove technology selection. The partner organisation was kind enough to lend us an experienced user researcher and service designer who started working in tandem with the build team. They were involved in familiarisation, user recruitment and research, sense-making, journey creation, prototyping and conducting the usability tests. Soon it became apparent that these activities were dependent on the availability of external users to participate in the user research. Which meant sprint planning became unpredictable and meaningless and our daily stand-up meeting became chaotic.

I could totally relate to their challenge of not being able to feed the scrum consistently.  This caused loads of pressure for the discovery/user research team and a frustration, ‘feast or famine‘ situation for the build team.

So here is a question…. should discovery teams be following Scrum methodology?

What did we do?

We split the team into ‘User Need’ and ‘Build’ teams. The ‘Build’ team continued following the Scrum methodology but the ‘User Need’ team started experimenting with Kanban. This approach definitely helped the ‘User Need’ team to list their activities and prioritise them. We could see loads of post-its on the wall and hear telephone interviews but to date, there were no shippable outputs/outcomes. The User Need team still needed to review the information that had been gathered before the user stories could be written.

We decided to introduce monthly planning, retrospective session and show-n-tell ceremonies and run the discovery team a few sprints ahead of the build team. This allowed them to complete user research, make sense of their finding, design user journey and come up with wireframes. Enough time for the Product owner to define-prioritise-refine user stories and feed them to our code monsters!

I would like to hear from User Researchers, Service Designers, Product Owners and Agile Coaches about their approach in government or private organisations.