If you feel like your habits around backlog and roadmap curation are a mess, discovery sprints are the answer.
Discovery sprints offer a formalized process for working through new feature ideas and improvements, so you can be sure you’re not willy-nilly adding stuff to your roadmap...but actually validating, prototyping, and testing everything you build.
What is a discovery sprint?
A discovery sprint is a collaborative process for validating new features and feature enhancements for software products, mobile apps, websites, and other digital experiences. Discovery sprints take product teams on a journey from ideation through prototype testing to ensure that teams don’t waste time on features with little to no impact on revenue.
Design sprint VS discovery sprint
Design sprints and discovery sprints are both structured, organized processes that help businesses build validated products and experiences for their customers—instead of guessing what users want and hoping your solution will fit the bill.
Although they share some similarities, design sprints and discovery sprints are very different. Design sprints are typically conducted in one to two weeks, while discovery sprints can run longer. Design sprints are done to validate an entire product concept, while discovery sprints are used to validate feature improvements or other roadmap additions.
A design sprint follows this process:
Map out the problem
Sketch different solutions
Decide which solution to move forward with
Prototype the solution
Test the prototype with users
A discovery sprint, on the other hand, follows this process:
Understand the impact of the feature
Sketch the feature
Prototype the feature
Test the prototype with users
Add validated ideas to your delivery sprint
When should you do a design sprint?
Because a design sprint is a formalized product validation process, it should be done as early as possible in product development. You should validate your product idea before committing to its development.
This allows businesses to save time and money, avoid building the wrong thing, and quickly bring the right concept to market.
When should you do a discovery sprint?
Discovery sprints should be run on an ongoing basis. Great software is continuously updated. The discovery sprint process can help you decide which feature ideas to approve and add to your development backlog.
Discovery sprints are great for validating both company-driven ideas and user-submitted feature requests.
Understanding how discovery sprints work
Before we dive into the step-by-step process, let’s consider the true meaning of the word discovery and how that impacts your product team.
What “discovery” really means
The process of discovery forces us to release our assumptions. Normally, entrepreneurs and product leads rush full steam ahead into development, without taking the time to admit their ignorance or spell out their assumptions. They just accept those assumptions as truth and barrel through the accompanying backlog.
But when we take the time to “discover,” what we’re really doing is admitting what we know for sure and what we don’t. For example, we might know that a handful of users have requested a feature. But we might assume that we know how to design this feature in a way that users will love.
When we go on a process of discovery, we stop assuming. We prototype our design and test it with users so we can be sure they’ll love the UX and functionality before we proceed.
How discovery fits into product delivery
Product updates are delivered continuously. By the same token, discovery should be handled continuously.
You‘ll be constantly collecting feature improvement ideas from your team and your customers and you need a way to work through these ideas—instead of assuming which ones to implement or letting good ideas rot.
Ideally, you should validate new ideas before they’re added to your team’s roadmap and backlog tasks. So that product delivery tasks are based off of your discovery process.
Below, we take a look at the easiest way to organize this work.
How to use the dual-track agile approach to manage discovery and delivery
Users wait for no one. You can’t pause development to run a discovery sprint. You need to run discovery sprints and delivery sprints concurrently.
That’s where dual track agile development comes in.
When following a dual track agile approach, you run two-week-long discovery sprints and two-week-long delivery sprints at the same time.
While your developers, DevOps engineers, product managers, and QA testers work on a delivery sprint, your product strategists, product managers, and UX designers will work together on a delivery sprint.
The validated concepts from the discovery sprint will be added to an upcoming delivery sprint based on their priority level.
Benefits of discovery sprints
Discovery sprints offer a ton of benefits that together represent a serious competitive advantage.
Agile innovation
When you use discovery sprints, you’re working in an agile fashion. Instead of letting product ideas and feedback pile up and reviewing it quarterly or annually, you have a short feedback loop. You continuously vet and validate ideas. As such, you get all of the benefits of agile innovation, like adaptability, faster time to market, customer centricity, and more.
Smaller bets
When you run discovery sprints, you’re placing small bets, not big ones. You validate, prototype, test, and approve small feature updates. This is in contrast to unorganized idea validation processes, where a flood of new improvements might get added to your backlog all at once. You’re better off developing small concepts and ensuring user engagement before moving on with the full feature or product idea.
Cost control
Discovery sprints seriously lower your costs. You only invest in developing ideas that have gone through your well-oiled discovery process. You don’t waste money on features users don’t want or won’t use.
Risk mitigation
Fewer assumptions equal fewer risks. No more guessing what will work and leaving your organization vulnerable to established competitors and new startups who will better listen to users.
Effective collaboration
Teams that run discovery sprints are much better at working through new feature ideas. Rather than argue over assumptions, you can follow steps. Everyone on the product strategy and design team will defer to users’ opinions instead of relying on their own.
How to run a discovery sprint
Follow these key steps to run a comprehensive discovery sprint.
1. Get the right roles on board
Before you begin, you need to invite the right collaborators to take part in your discovery sprint.
Make sure to have these essential roles covered:
Product owner - The product owner is responsible for managing the product, its development, and its quality. In some cases, the product owner and decision marker are one in the same.
Scrum master - The scrum master helps deliver insights and learnings from other teams while keeping the discovery sprint process on track and on time.
Solution architect - The solution architect will provide information on required technologies and development feasibility, making it easier for the business analyst to calculate costs.
Business analyst - The business analyst will help determine the financial impact of the proposed features, and their potential ROI relative to the cost of development.
UX designer - The UX designer is responsible for developing the high-fidelity prototype that you will show to users to collect their feedback.
Decision maker - The decision maker has the ultimate say in which sprint ideas will move onto development. This person might be the company founder, a business executive, or the product manager.
2. Prioritize ideas for discovery
Although a discovery sprint helps you validate and prioritize what to build, you’ll still need to do some upfront work to determine which product ideas to tackle in your next discovery sprint.
Because a discovery sprint should be tight and focused, you need to prioritize topics and ideas.
Consider this framework for prioritizing product improvements:
“Many products have failed because owners and product managers did not focus on the right features and prioritized the ones they thought were important. A feature prioritization framework can help you build products that are helpful, easy to use, and with great UX. To help create this framework, you can use the RICE Score, where you score on a scale of 1 - 5 each of the following categories for a given feature idea: reach (how many customers will be positively impacted), impact (how intense will the impact be), confidence (how confident are you in the potential reach and impact), and effort (how much effort will be required).” - Philipp Wolf, CEO of Custify
You might also want to ask yourself some important questions, like:
Will this idea impact our target users?
Can we reasonably gather the information we need to understand this issue?
Do we have evidence that solving this problem will positively impact new revenue or decrease churn?
Do we expect to be able to solve this issue relatively easily, and without changing our core technologies?
Will fixing this problem future-proof our business?
Are there other feature concepts that will affect a greater number of users?
Will this feature help us keep up with competitors, or outpace them?
The answers to these questions will help you choose the highest priority concepts to discover.
3. Scope out your discovery sprint and write clear questions
The next step is to scope out your discovery sprint and write a set of discovery sprint questions.
If possible, limit each discovery sprint to one topic. However, if the feature ideas are small or easy to accomplish, you can review a few concepts in a single sprint.
For example, the scope might be to determine the viability of adding a helpdesk feature to your software.
The discovery sprint questions might be,
Will users abandon our product if we don’t offer a helpdesk feature?
Do our target users expect us to have a helpdesk feature?
How long will it take to develop a helpdesk feature?
How much will it cost to develop a helpdesk feature?
How will adding a helpdesk feature impact revenue?
As you move through your discovery sprint, you’ll be able to answer these questions, which will ultimately help you decide whether or not to build that feature.
4. Understand user needs
Now, it’s time to really dive into what your users want and need. The more complex the feature being discovered, the more effort you should put into user research. If the proposed concept is costly, you should survey or interview a greater number of users to be sure you understand their needs accurately.
5. Sketch the solution
Working as a team, sketch out your proposed solution to this user need. You might sketch out a few different feature ideas and choose the best one. Work together on a physical or digital whiteboard.
Once you’ve clarified the essential user needs and the interworkings of the proposed solution, you can move onto prototype design.
6. Prototype the feature(s)
Next, your UX designer This could be a low-fidelity prototype or it can be fully branded (recommended) so that users really understand what the feature will look and feel like.
For example, if you’re considering redesigning the main product dashboard, you would prototype the new design precisely, so that you have the exact proposed concept to show to users. The more accurate the design, the more accurate the feedback you’ll collect.
7. Conduct user testing on your prototype(s)
Now, you need to show this prototype to your users. Schedule user testing sessions with 5 to 50 users. The more expensive and complicated the proposed feature, the more users you should talk to. During the session, show them the proposed feature or update and allow them to click around on the prototype as they wish.
Make sure to collect feedback not only on the design, but the importance of the feature (or lack thereof). Record the sessions and use manual review processes or AI research tools to gather top trends and insights. You’ll want to categorize your feedback into what’s validated and what needs improvement.
8. Reiterate or add approved features to your delivery sprint
The final step is based on the outcome of your discovery sprint.
Discovery sprint outcomes
Ultimately, a well-run discovery sprint should only produce one of three outcomes:
Not validated - The feature idea might not be validated. Even if one user requested it, it might take your roadmap in the wrong direction, or have you catering to the wrong user segment.
Needs to be reiterated - Maybe your discovery sprint results are that the concept is approved, but the solution needs more work. You’re not ready to add this to a delivery sprint. Your UX designer needs to create a new prototype and test it first.
Validated and ready to plan for development - The last outcome is that the feature is validated and your prototype is up to your users’ standards. It should get added to the next delivery sprint, or an upcoming one based on priority.
How Devsquad conducts discovery sprints
DevSquad offers continuous discovery sprints as part of our product strategy and design services.
We use a dual track agile development approach. And for new products, we offer design sprints so that you can be sure you’re taking a validated MVP to market.
