Agile and working with users — discovery

In plain terms, agile means building software in short, repeatable cycles and checking in with the people who'll actually use it along the way — instead of building for months against a fixed spec and only finding out at the end that the spec was wrong. Discovery is the specific practice of talking to real (or realistically representative) users early, to learn what they actually need and how they actually behave, before — and while — you build.

Here's why that belongs on a testing page: a test suite can only check that software does what you intended it to do. It has no way of checking whether that intention was ever the right one. Discovery is what keeps the intention pointed at something a real person actually needs, so that all the careful automated checking you do afterwards is checking something worth checking.

It's concrete on this very site, too: the fixture examples on the practice page, and the NHS Wales "About Us" and search scenarios this site's sibling repos exercise, exist because someone identified a real user journey worth protecting — signing up, searching, finding information on a health service site. Deciding that journey mattered enough to write a test for is itself a discovery activity, not a purely technical one.

Learn more at the Agile Manifesto and the Nielsen Norman Group's introduction to user research, or watch "Agile Methodology Explained in 5 Minutes" for a video introduction.

Examples you can ask AI

What does 'discovery' actually mean in agile, and why would that matter to someone who just writes test scripts?
How do I turn a vague user story into a concrete, testable scenario before I start automating it?
How do experienced teams keep discovery and test-writing connected on an ongoing basis, rather than discovery happening once up front and the tests drifting from it later?