The goal of discovery is to learn about a problem or opportunity before developing solutions. Discovery involves gathering information from multiple methods and sources to determine whether a problem is worth solving or an opportunity warrants further pursuing. Discovery provides insight into how to approach the problem, what factors to consider along the way, and what success looks like. At the end of discovery, teams should be able to formulate a problem or opportunity statement and confidently propose potential solutions.

Discovery and Agile-Sprint Timing
Practitioners often ask us, "How can we fit discovery in Agile?" We typically answer with a reminder that Agile isn't about moving fast or recklessly: it's about prioritizing and delivering small, high-value increments to users, early and often. Discovery gives us the information we need to understand what’s valuable to our users and organizations, and thus the ability to do iterative product development well.

UX professionals often find it challenging to do discovery work in Agile, so they rush or skip it entirely. Or teams think that all discovery activities must be completed by the end of a sprint. The tight timeframes make discovery feel like a lost cause, so teams omit it from the Agile process and rush to features and solutions instead –- a risky approach.

While it's important to timebox discovery, don't arbitrarily use sprint length to set timing for your discovery research. When this happens, teams risk hurrying discovery activities and working from short-sighted or incorrect information. Finishing work within a single sprint is important for releasable increments, but not critical for ongoing user research.

Scaling Discovery in Agile
A healthy mindset for discovery in Agile is to scale it, not skip it. Scaling down discovery helps teams prioritize it when needed and maintain the perspective to sustain it continuously. Focus narrowly on the most specific and valuable activities and areas of investigation. Address targeted questions and work to verify probable assumptions, rather than every possible question or assumption your team may have.

What does this look like, practically? We can use the word SCALE as a mnemonic.

Use the word scale to remember how to effectively scale discovery in Agile.
Scaling discovery work in Agile keeps it within a reasonable and manageable scope. The word Scale provides guidance and practical reminders for how collaborate and communicate while learning.
Use standup meetings and other Agile events to communicate with others. When you complete an activity, write down what you learned, implications, and next steps in a 1-page recap. Reread it for coherence before sharing it face-to-face in a quick meeting or recording. During busy sprints, use physical or digital sticky notes in an organized evidence board to communicate learnings and share progress.

Speak and spike: Speak to your team and stakeholders often, to stay informed and anticipate when you need upcoming time for discovery. Add a theme or initiative to your roadmap to get ahead of any possible feature-delivery work that lacks context and evidence. Doing a bit of discovery preplanning can also initially align teams on what they may eventually need to do. Once you know you need discovery, add a spike to your sprint backlog during backlog grooming or refinement to balance the discovery time with other delivery work in the sprint. Constrain spikes to 1-2 key questions and choose research methods that will provide specific answers. Complete spikes as early as possible in the sprint.
(In Agile, a spike is dedicated time during a sprint for user-focused or technical research. It is typically added to the backlog to account for unpredictable factors — issues that will require a yet-unknown amount of time or effort to address.)

Talk about what you already know and what is unknown about the problem or opportunity. Have each team member fill out a problem or opportunity statement, using the same template or evidence board. This will surface how each person sees the problem or opportunity and invite discussion from different perspectives.

An example of a problem statements board.
Before discovery, Agile teams can diverge to write individual variations of problem statements. Then, converge to efficiently discuss the various perspectives and resolve misalignments. Work together to create an overall statement that will scope discovery work; the overall statement could be merging parts from different problem statements.
Capture where the team is aligned and where conflicts or knowledge gaps exist. If these are left unchecked, they could jeopardize future sprints by wasting time and money on something that people won't use or that will negatively impact internal processes. Discuss the discovery activities you need to do to resolve conflicts and close the knowledge gaps. It could be just a few of the following:

Reviewing business documents
Speaking to stakeholders
Technical research
Analyzing competitors
Checking analytics
Examining past research
New user research
Heuristic evaluation

There's more to discovery than user research alone and discovery doesn’t have to involve every possible research method. In an ideal scenario, perhaps you'd conduct a large-scale diary study, run a usability test of the current experience, hold stakeholder and user interviews, and listen in on customer-support calls, all of which would likely take a few months. Since we rarely work in ideal scenarios, prioritize the most valuable discovery activities needed to acquire the missing information in the time available. Just because you could do a discovery activity doesn't mean you need to. Align activities to specific questions or assumptions to keep the discovery scope and timeline realistic.

Assign discovery activities to appropriate Agile-team members. Discovery in Agile isn't exclusive to UX or product managers. The entire Agile team needs to participate; creating great experiences takes more than quality code or design. Working together in discovery means time saved in delivery, as the team will have the same understanding of the problem or opportunity. Certain team members, such as engineers, likely won’t be in discovery mode the whole sprint. In reality, the Agile team will have to intentionally divide time between discovery and supporting delivery, which is why focusing on only a few small-scoped, high-value priorities at a time is important.

Determine who on the Agile team is best suited to lead activities and gather information. If you need information from a C-level leader, rely on your product manager or owner; if you need user research or heuristic evaluation, that's for UX. For understanding technical limitations, lean on your lead engineer. Figure out what to do together and where to work solo.

Use the activities and assignments to estimate how long discovery will take. It doesn’t matter whether it wraps up in a single sprint or spans multiple sprints. The goal isn't just to get the activities done, it's to get the critical information needed to deliver value and lower risk as soon as possible. If discovery is going to take 2–3 sprints, that's fine –- just don't let it drag on and on. Deliver on your discovery commitments to maintain the credibility of the process.

If discovery has to wrap up in a single sprint, try to learn more about what's driving the deadline. You may have to work from data and information you already have or that can be obtained through efficient means, such as secondary research. Outline the risks of forging ahead without enough information and track metrics to show what happened as a result of rushing or skipping discovery.

Learn and share: You don't always need a fancy presentation or complex map to recap what you learned in discovery. Analyze, synthesize, and communicate the information learned as you go to avoid wasting time on end-of-discovery analysis paralysis.

Evaluate and decide. As you and your team complete discovery activities, come back together and assess if you have all the knowledge you need at this point. Do you need more? Can you get that information in this sprint or the next? Do your plans need to stay on hold until you have more information? Or can you move forward with meaningful ideation, given the learning and evidence you have? Make this decision together and stick to it!

At the end of the discovery iteration, don't just hand over a solution idea to developers. Plan space in your subsequent sprint backlogs to prototype, test, and iterate on potential solutions. As much as possible, try to get the design right before delivery begins, then iterate further from there.

What Enables Discovery in Agile
There are a few factors that help support successful discovery initiatives in Agile:

Have UX represented in organizational leadership to provide ongoing advocation for balancing time for discovery with time for feature delivery. UX leaders can initiate and maintain the dialogue to ensure that UX is involved early and often to get ahead of and anticipate the need for upcoming discovery.

Track the time saved in delivery. For any skeptics who focus on velocity or feature delivery over discovery, Scrum masters or delivery managers can help UX practitioners track how discovery speeds up decision making and increases the quality of the decisions made. You can use discovery velocity to quantify the units of information or knowledge acquired during discovery work in a sprint in the same way in which delivery velocity measures the units of work completed during a sprint. Tracking discovery velocity over time will also help estimate the time needed in discovery and set expectations for the types of information and level of detail that can be realistically achieved during sprint timeframes.\\

Avoid the temptation to preemptively assign delivery tasks to Agile team members before discovery work is complete. We don't want engineers to start building a solution before we know whether it has the potential to succeed. If discovery reveals we can't do much technically to solve a problem, or there are internal process constraints, it will be wasteful to shift priorities or stop abruptly after delivery has started. Have the right conversations upfront to set expectations about what activities are appropriate in discovery and what will come after.

And finally, don't start from scratch for every discovery activity. Maintain and modify premade templates to fit the scenarios you're gathering information about. Establish repeatable processes for scheduling sessions, recruiting users or stakeholders, developing tasks and interview questions, sharing findings, ideation, and decision making. These processes will make discovery more efficient and less daunting.

Discovery in Agile is about understanding problems and opportunities in small, but feasible, iterative increments. Be specific about what discovery activities are valuable and how much time should be spent on them, so you can gather the information necessary to make good decisions about next steps in the pursuit of value. To succeed with discovery in Agile, scale it, don't skip it.