Continuous discovery is the ongoing work of an interdisciplinary team of developers, UX experts and business representatives who learn together what problems the customer has before features go into the backlog. Scrum expects a finished backlog but says nothing about how it gets built. Methods such as event storming and user story mapping help close that gap.
Key Takeaways
- Scrum assumes a finished, prioritized backlog but never explains where good requirements come from, and that blind spot is what eventually costs teams their relevance.
- User story mapping and event storming put developers, domain experts and users in one room, and the discussion there creates a shared understanding that no document can replace.
- Gemba walks, meaning visits to users where they actually work, uncover workarounds and gaps in usage that a development team simply cannot see from a distance.
- An interdisciplinary team needs a few people with a clear domain focus. Not every developer wants to or has to master the business domain, but that perspective has to be present somewhere on the team.
Scrum Optimizes Delivery, Not Discovery
Scrum is built almost entirely around delivery and leaves out the discovery phase. The Scrum Guide takes a finished, prioritized backlog for granted and never says how the requirements get into it. Continuous discovery fills that gap: the whole team keeps learning about the customer’s problems instead of waiting for a list of requirements.
The gap is deliberate. The Scrum Guide keeps the product owner role vague and outlines its responsibilities only loosely. A few pages can’t cover every problem a project runs into, and that’s fair enough. But it pushes the hard question further down the road: which methods help you build a good backlog, and how do you get feedback from the customer quickly?
At this point Scrum pulls in two directions. On one side is the shippable product increment with high quality standards. On the other is the need for feedback as early as possible. If you build an idea properly and ship it before you ask, you often learn too late that the customer never needed it. The focus belongs on the outcome, not just the output.
Why Domain Expertise Belongs in the Development Team
Developers who work through the next backlog item without understanding the problem behind it produce output without impact. Ina Einemann sums up this attitude bluntly: the team grabs the next item, builds it and has no idea what it’s for from a business point of view. That model doesn’t hold up.
“Don’t bother me with the business domain” sounds like a developer’s complaint, but the point is the opposite. Domain knowledge isn’t the problem, it’s the precondition. Without understanding the domain, you can’t solve the customer’s problem. You can only copy it blindly.
What matters is which way the knowledge flows. It doesn’t stay in the business department, which talks to the customer on its own and hands requirements down. The whole team learns together how the customer thinks and what problems they have. Innovation often comes from the technical side. Developers who know the problem space bring in ideas that a business department on its own would never see.
This shared discovery must not turn into a mini waterfall. An upstream discovery team that tests ideas and passes them down the line misses the point. The whole interdisciplinary team learns together.
Event Storming and User Story Mapping Get Everyone in One Room
Both methods start the same way: every perspective in one room. Users, product owners, business owners and the technical side. People work with sticky notes and get going right away, without learning a notation like UML first.
Sharing a room is the heart of it. The same discussions simply don’t happen online. The real value lies in the direct exchange, for example when two users realize they define the same term differently and the workshop makes that visible. Walking through a finished map afterwards has some value, but not the same.
User Story Mapping Builds a Two-Dimensional Backlog
User story mapping collects activities and breaks them down step by step, starting from a high altitude. Take “getting up in the morning”: the top row reads “go to the bathroom”, “eat something”, “leave the house”. The next level below holds steps like “get dressed” and “take a shower”. At the bottom are fine-grained steps such as “step into the shower” and “pick up the shampoo”.
You can prioritize within each column. Leaving the house dressed is a must, washing your hair that day is optional. Walk through the whole process from start to finish once and you get a complete end-to-end slice. The result is a two-dimensional backlog in which the top row gives you the first user stories directly.
Event Storming Sharpens Service and Team Boundaries
Event storming starts small and collects the business events that happen in the application. Events are phrased in the past tense because they are complete: “invoice was sent”, “order confirmation was sent”. Nothing can go wrong with them anymore.
Later, more colors join the wall: people, external systems and commands. Commands are written in the present tense and show that besides the happy path there are error cases too. With this more detailed model, you can start cutting the process into pieces.
That makes event storming a good basis for drawing service boundaries, and from those, team boundaries. It works for kicking off large projects as well as for modularizing inherited legacy applications, where it becomes more technically driven.
| User Story Mapping | Event Storming | |
|---|---|---|
| Direction | Top down, from big to small | Bottom up, from event to process |
| Building blocks | Activities in columns | Events, commands, people, external systems |
| Result | Prioritized, two-dimensional backlog | Service boundaries and team boundaries |
| Typical use | Building the backlog, end-to-end slice through the product | Project kick-off, modularizing legacy applications |
Continuous Discovery Doesn’t Stop After the Kick-Off
The most common mistake is treating discovery as a one-off start. A kick-off workshop creates the big picture and a shared understanding, and that’s a strong beginning. The hard part is keeping the learning going once the project is running.
Many teams don’t even live the feedback loops that are already in the Scrum Guide. The review is meant to be a working session where stakeholders give feedback and everyone reworks the backlog together. In practice, often not even that happens.
Continuous discovery means looking at the modeled parts of the process on a regular basis and checking whether the model still matches the business domain and still solves the problem. This is where a digital tool like Miro earns its place, because process models are easier to maintain there than on paper.
A Gemba Walk Shows What Users Really Do
If you watch users over their shoulder where they work, you see the workarounds the development team would otherwise never hear about. A Gemba walk makes visible where people rely on makeshift solutions and where the real problems are.
Seeing this firsthand changes the energy in a team. After a visit to the production halls where the software is used, new ideas and a new understanding emerge. It’s a bigger block of time that needs planning, but it gives the team a real boost.
Not every application can be observed on site. When the end user is hard to reach, a prompt inside the system helps, some kind of questionnaire or interview technique that involves the user in the process as much as possible. The key is that users are open to experiments like that.
Fast Feedback Without a Finished Increment
You don’t have to make an idea shippable to find out whether the customer needs it. That misunderstanding is exactly what wastes time: if you build everything to a high standard up front, you test the idea too late.
A paper prototype or an interview is often enough to explore an idea before development starts. UX experts and domain experts on the team do this groundwork. Developers don’t have to spend their days running interviews, but they learn along the way what the customer wants.
“Nobody wants to build something that nobody uses. Even if it’s technically challenging and fun, if nobody uses it afterwards, that’s how you win over the skeptics too.”
(Ina Einemann)
Mixed Teams Win Over the Skeptics
Not every developer wants to dig into the business domain, and that’s fine. Some want to go deep into the technology, the backend or the frontend. Domain knowledge is too broad for one person to cover all of it.
That’s why every team needs a mix. Just as you need backend and frontend experts, you need one or two curious colleagues with a domain focus who keep discovery moving. In the review they show what they learned in the last sprint, and in the daily they agree on which experiments come next.
You don’t win skeptics over by making discovery mandatory, you win them over with its benefits. Once a developer sees that these colleagues keep him from building something nobody uses, he gets the value. He doesn’t have to do it himself. He just has to accept that it matters.
An Internal Hackathon Brings Ideas Back from the Technical Side
Once developers understand the problem space, it pays to let them work out for themselves which features they would build. A small internal hackathon gives them exactly that room.
The results can be surprising. After one such hackathon, customers gave strong feedback because it solved problems nobody had been focusing on and nobody knew could be solved so quickly. Turning that into something shippable takes some rework here and there. The real gain is the flow in the other direction: ideas from the technical side make their way back into the business domain.
Frequently Asked Questions
Does Scrum cover how good requirements are created?
No. The Scrum Guide assumes a complete, prioritized backlog and leaves open how the requirements end up there. It also describes the Product Owner’s responsibilities only in broad terms. Scrum focuses on delivery and leaves discovery out of the picture. Anyone who wants to build a viable backlog must adopt methods for doing so on their own, such as user story mapping or event storming.
Should domain expertise remain with the business unit that communicates with the customer?
No. If the business unit is the only one talking to the customer and simply passing on requirements, the team is missing out on ideas. Innovations often arise in the technical domain: developers who understand the problem space see solutions that a purely business-oriented unit wouldn’t think of. It makes sense for the entire team to learn together how the customer works and what problems they face.
When is Event Storming a better fit than User Story Mapping?
Event Storming works from the bottom up, collecting business events in the past tense and later adding commands, people, and external systems. This results in service boundaries, and based on those, team boundaries. It’s well-suited for launching large projects and for modularizing inherited legacy applications. User Story Mapping, on the other hand, moves from the big picture to the details and delivers a prioritized backlog.
How is a two-dimensional backlog different from a list?
In addition to order, it has a second axis: activities are listed in columns, with increasingly granular steps below them. Within each column, items can be prioritized, for example “leaving the house dressed” as mandatory and “washing hair” as optional. Anyone who goes through the top row from start to finish gets a complete overview of the process and, from that, the first user stories.
Can discovery workshops like Event Storming be conducted remotely?
The real value lies in being in the same room, and the same discussions don’t happen digitally. The crucial moments are when two users realize they define the same term differently. Simply going over a finished map later is valuable, but not in the same way. For ongoing maintenance of the process models, however, a digital tool like Miro makes sense.
Is a kick-off workshop enough to ensure a shared understanding?
No. The kick-off provides a big-picture view, but the most common mistake is treating discovery as a one-time kickoff. The challenge lies in keeping learning an ongoing part of the process: regularly reviewing the modeled process components and verifying whether the model still aligns with the business domain. Many teams don’t even follow the feedback loops outlined in the Scrum Guide.
How do you get user feedback when the end user is hard to reach?
In that case, a prompt within the system (a questionnaire or interview technique, for example) can help, as it involves the user in the process as much as possible. This requires that the user be open to such experiments. On-site, a Gemba Walk reveals the workarounds and makeshift solutions that the development team would otherwise never learn about from a distance.
Does an idea have to be built to a deliverable state first to find out if customers need it?
No. A paper prototype or an interview is often enough to explore an idea before development begins. If you build everything to a high standard in advance, you’ll test it too late and only find out after release that nobody needs the feature. UX and domain experts on the team handle this preliminary work; developers learn along the way without having to conduct interviews themselves.
