Discovery sprints: What they are and why you should run them
Empowering Agile teams to build the right thing.
As a Product Designer at an agency, running product discoveries within a project involving a few Agile teams, I’m familiar with the struggle of squeezing discovery work into a busy Agile environment. The team is always rushing to build and release something, and in this race there is very little time to stop and think about what you are actually building.
That’s why my colleague Kathrin Höfer and I embarked on a journey to empower our teams to run smoother discoveries and build the right thing, and in our two articles, we’ll show you what we did and how you can apply our tools within your teams, too.
In this article, I’ll be talking about what discovery actually is and why you should do it, the challenges and pain points we saw in our teams, as well as some of our solutions to these challenges.
Unknown lands and admitting ignorance
By this point, I already mentioned the word discovery a bunch of times, but some of you may be wondering, what is this discovery thing? Let me try and clarify that.
In his book Sapiens, Yuval Noah Harari talks about the two maps of the world you can see below, which were designed in the thirteenth and fourteenth century, respectively.
The map on the left is from 1459 and it shows what was the common approach in cartography at that time: mapping what is known by observation (see how Europe is well defined and close to what we know it to be), and then filling in the blanks with myths or legends about the areas that were not known yet, such as made-up lands and edges of the world or even monsters here and there.
Around 1525, Nuño García de Toreno drew the second map, which is called the Salviati Planisphere. This map has an entirely new approach: mapping what was known by observation, but then leaving the rest empty.
This approach is quite unique because, as humans, we want to fill in the blanks, we fear the unknown and the empty space. So these empty spaces in the map represent a huge leap forward in human knowledge: admitting ignorance. Accepting that we don’t know everything is the first step towards knowledge.
“Anyone looking at the map and possessing even minimal curiosity is tempted to ask, ‘What’s beyond this point?’ The map gives no answers. It invites the observer to set sail and find out.” Yuval Noah Harari, Sapiens
Ok, but what is discovery then?
Now, you might wonder, what does this tell us about product development and discovery?
Think about the first map again. It’s finished, it’s complete, it’s well drawn, but is it a successful product when it comes to representing the real world? Often in product development we get feature requests or even briefs for new products and we jump to solutions: we or the client think we know what is the right thing to build, and we go as quickly as possible to fill in the blanks and build it based on assumptions and myths about our users, the business or our technical capabilities.
As much as it’s natural to do so, we have to question things and find empirical evidence to support our answers if we want to build a product that has a much bigger chance of being successful. This is exactly what discovery is to me:
- Mapping what you know empirically
- Admitting you don’t know the rest, while resisting the temptation to fill in the blanks with assumptions
- Planning steps and actions to go out there and observe reality to paint a full picture, validate your assumptions and answer your uncertainties
As Tim Herbig puts it,
“A Product Discovery describes the iterative process of reducing uncertainty around a problem or idea to make sure that the right product gets built for the right audience.” Tim Herbig
Discovery and product delivery
Discovery is part of a broader process that has to do with crafting products and services for people. At some point, you have to actually deliver those products or services. So how does discovery relate to delivery?
The latter is about how you build something, whereas the former investigates what you should be building in the first place, before you even start building it.
Here below you can see the cycle of product delivery. Ideas come from users and strategy, and you might just want to save time and jump to delivery to bring value to your users as soon as possible. But developing a solution takes time and effort, which means money. So if you jump straight from idea to development, you’ll still have a lot of risks and there’s a big chance you’ll waste a long time building the wrong thing and you’ll find out too late.
Discovery gives you a shortcut to validation. An opportunity to find out if your idea works before you invested too much time and money on it.
The challenges with discovery and Agile
What I’ve described so far is the ideal process, but reality is far more complex and there are some contexts, teams and projects where it’s actually very hard to implement all this.
Let me tell you a little bit about our own experience. We at Accenture Interactive are a consultancy, meaning that we have a number of clients, existing ones and new ones, that approach us with product or service ideas.
When a new client comes in with a new product or service idea, this is somewhat simpler. As we go through the briefing, questions arise, generally revolving around four main risks, as described by Marty Cagan:
Value risk (whether customers will buy it or users will choose to use it)
Usability risk (whether users can figure out how to use it)
Feasibility risk (whether our engineers can build what we need with the time, skills and technology we have)
Business viability risk (whether this solution also works for the various aspects of our business)
To answer these questions, we typically propose a discovery project with a small, dedicated team that will run some research, ideation and validation with potential end users. If the idea is validated, we then offer a whole new contract with a bigger development team to actually build and deliver the product.
But what if the client is not new and you are working on an existing product? The client will still have ideas for new features, and you will still have questions about their value, feasibility and viability. Only this time you are already in full delivery mode and you have developers waiting for you to come up with designs and user stories and start building.
If you don’t have a dedicated discovery team, it’s very tempting to find excuses not to do any discovery work and jump straight to delivery. We wanted to prevent exactly that, so our challenge became clear:
Our team’s pain points
In order to understand what creates friction and causes team members to try and avoid discovery, we ran one-to-one interviews with people from each role—Designers, Solution Architects, Business Analysts, Product Owners—so that we could solve their pain points and get their buy-in.
These are what we found to be the biggest obstacles for people when it came to discovery:
- Not knowing when a discovery is needed
- Unclarity on roles and lack of involvement
- Time and effort concerns
- Lack of a structured workflow
Our solutions
To solve these pain points we ideated and co-created some tools and practices, which we tested and iterated upon, and we are now happy to share our step-by-step guide with you.
I’ll start here by taking you through the very first steps when setting up a new discovery: understanding when you need one (Definition of Needed), prioritizing discoveries and scoping them, as well as a clear overview of the roles you might need in your team and what these people might be doing in a given discovery.
Do you need discovery? Definition of Needed
Our first step is a definition. Agile teams tend to create definitions of Ready and Done for product delivery together and as a team, so we did the same here for discovery and co-created our definitions, including a Definition of Needed.
A discovery can be big or small depending on the uncertainties we have and how big they are but, as a rule of thumb, if there are no uncertainties we may not need a discovery at all. Within this context, assumptions and personal opinions need to be considered uncertainties.
We came up with a list of questions to go through when evaluating a new idea and assess whether or not you need some extent of discovery work before you start building it.
Prioritizing discoveries
But what if you have a lot of ideas? Maybe a bunch of them met your Definition of Needed and therefore you decided they might need at least some degree of discovery work, but you don’t know which one to pick up first. If that’s the case, you can use a tool such as the Uncertainty-Impact Matrix to prioritize them.
Discoveries are about solving uncertainties. The bigger the uncertainty is about an idea or feature, the more discovery work is needed. Those ideas will end up in the top quadrants.
On the other hand, the more something is clear under all aspects (desirability, viability, feasibility, and usability) and the fewer assumptions we have, the more we can avoid spending too much time on discovery and move on to execution earlier. Those are the ideas that will populate the bottom quadrants.
Scoping discoveries
It can also happen that an idea is just way too big for one discovery sprint, and we try to keep our discovery sprints within the same duration as our delivery sprints (2 weeks). In that case, you might want to split the scope in multiple, more manageable, discoveries and organize them in a sequence that makes sense.
Roles checklist
One of the pain points we found was an unclarity on roles and responsibilities. Who should be involved in discovery and what should they be doing?
Discovery should be a collaborative effort since every team member can bring some valuable insights and nobody can possibly consider all the perspectives that are needed in order to assess and solve a problem on their own.
Please see our role checklist (which was developed collaboratively during a cross-disciplinary workshop) as a guideline to start discussing how much time and effort each individual can contribute to the discovery.
In this article we’ve looked at what discovery is, what its challenges are, and how you can identify, prioritize and scope discoveries, so you can get started working on one.
If you are interested in more details on how to get started with a new discovery, check out this article, written by my colleague Kathrin Höfer: How to kick-off Discovery Sprints, reframe a problem and align your team.
🚀And by the way, all the tools we mention here are included in our Discovery Kickoff Workshop Template for Miro and MURAL, which are free for you to use.
References
I’m a Product Designer currently crafting meaningful digital products and experiences at Accenture Interactive Amsterdam, where I apply user-centered design principles and methodologies to make technology human. If you want to get in touch or have any feedback, you’ll find me on LinkedIn.
