Discovery in Agile

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 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.

• 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.

‍