Don't give me technicality

Continuous discovery refers to the process in which an interdisciplinary team of developers, UX experts and departmental representatives work together to continuously understand customer problems before features are added to the backlog. Scrum requires a finished backlog, but leaves open how it is created. Methods such as event storming and user story mapping help to close this gap.

Key Takeaways

• Scrum assumes a finished, prioritized backlog, but does not clarify how good requirements are created in the first place: it is precisely this blind spot that costs teams relevance in the end.
• User story mapping and event storming bring developers, business experts and users together in one room and create a shared understanding through discussion that no document can replace.
• Gemba Walks, i.e. on-site user visits, uncover workarounds and gaps in use that the development team simply cannot see from a distance.
• An interdisciplinary team specifically needs people with a specialist focus, because not every developer wants to and should be able to penetrate specialist knowledge, but these glasses must still be present in the team.

Scrum optimizes delivery, not discovery

Scrum focuses almost entirely on delivery and ignores the discovery phase. The Scrum Guide assumes a completed, prioritized backlog. How these requirements get into the backlog in the first place remains open.

This is precisely where there is a gap. The Scrum Guide deliberately keeps the role of the product owner vague and only roughly describes their responsibilities. Not every project problem can be covered in just a few pages. This is legitimate, but it pushes back the really difficult question: Which methods help to build a good backlog and how do you get feedback from the customer quickly?

Scrum pursues contradictory goals at this point. On the one hand, there is the deliverable product increment with high quality standards. On the other is the need for feedback as early as possible. Anyone who first builds and delivers an idea properly often finds out too late that the customer doesn’t need it at all. The focus should therefore be on the outcome, not just the output.

Why expertise belongs in the development team

Developers who only work on the next backlog item without understanding the problem behind it deliver output without impact. Ina Einemann describes this attitude in a nutshell: the team takes the next item, implements it and does not understand what it is for. That is not a sustainable model.

The title “Don’t give me professionalism” means the opposite of what it says. Professionalism is not the problem, it is the prerequisite. Without an understanding of the domain, the customer’s problem cannot be solved, it can only be blindly recreated.

The important thing is the direction. The expertise does not remain in the specialist department, which talks to the customer alone and passes on requirements. Instead, the whole team learns together what makes the customer tick and what problems they have. Innovations often arise in the technical area. Developers who know the problem space contribute ideas that a purely specialist department would not see.

This joint discovery must not become a mini-waterfall. It’s not about building an upstream discovery team that tests ideas and passes them backwards. It’s about an interdisciplinary team that learns together.

Event storming and user story mapping bring everyone into the same room

Both methods start the same way: all perspectives in one room. Users, product owners, business owners and the technical side. The participants work with stickies and get straight to work without having to learn a notation such as UML beforehand.

The shared space is not a detail, but the core. The same discussions do not arise digitally. The real value lies in the direct exchange: when two users realize that they define the same term differently and this becomes visible in the workshop. Simply talking through a finished map later has a value, but not the same value.

User story mapping builds a two-dimensional backlog

User story mapping collects activities and breaks them down step by step from a high altitude. For example, “get up in the morning”: the top row is “go to the bathroom”, “eat something”, “leave the house”. Below this is the next level, such as “get dressed”, “take a shower”. At the bottom are fine-grained steps such as “go into the shower”, “pick up shampoo”.

You can prioritize within each column. Leaving the house dressed is mandatory, washing your hair that day is unnecessary. If you go through the entire process from start to finish, you get a complete overview. The result is a two-dimensional backlog in which the top row directly delivers the first user stories.

Event Storming sharpens the service and team cut

Event Storming starts on a small scale and collects technical events that happen in the application. Events are formulated in the past because they have been completed: “Invoice has been sent”, “Order confirmation has been sent”. Nothing can go wrong here.

Other colors are added later: People, External systems and Commands. Commands are in the present tense and make it clear that there are also error cases in addition to the happy path. The process can be cut from this more precise modeling.

Event Storming thus contributes to a good service cut and, building on this, to a good team cut. It is suitable for the start of large projects as well as for the modularization of adopted legacy applications, then technically driven.

Discovery does not stop after the kick-off

The most common mistake is to treat Discovery as a one-off kick-off. The kick-off workshop creates a big picture and a common understanding, which is a strong start. It becomes difficult to maintain this continuous learning in the ongoing process.

Many teams do not even live the feedback loops that are in the Scrum Guide. The review is intended as a working meeting in which stakeholders give feedback and the backlog is revised together. In practice, this often doesn’t even happen.

Continuous discovery means regularly looking at the modeled process parts and checking whether the model still fits the technicality and still solves the problem. At this point, a digital tool such as Miro is also useful because process models are easier to maintain there than on paper.

The Gemba Walk shows what users really do

If you look over the user’s shoulder on site, you can see the workarounds that the development team would otherwise never hear about. The Gemba Walk makes visible where users are working with workarounds and where the real problems lie.

This direct observation changes the energy in the team. After a visit to the production halls where the software is in use, new ideas and a new understanding emerge. It’s a bigger block that needs planning, but it gives the team a boost.

Not every application can be observed on site. If the end user is difficult to reach, a query in the system, a kind of questionnaire or interview technique that involves the user in the process as much as possible, helps. It is crucial that they are open to such experiments.

Quick feedback is possible without a finished increment

You don’t have to make an idea deliverable first in order to learn whether the customer needs it. It is precisely this misunderstanding that costs time: if you build everything to a high standard in advance, you are testing too late.

A paper prototype or an interview is often enough to sound out an idea before development starts. This preliminary work is carried out by UX experts and technical experts who are part of the team. Developers don’t have to conduct interviews all day, but they learn 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, you’ll get the skeptics.

Ina Einemann

Mixed teams also win over the skeptics

Not every developer wants to dig into the technical side of things, and that’s fine. Some want to dig deep into the technology, into the backend or frontend. The knowledge of the domain is too broad for one person to do it all.

That’s why every team needs a mix. Just as you need backend and frontend experts, you also need one or two curious colleagues with a technical focus who continuously initiate discovery. They show what they have learned in the last sprint in the review and agree in the daily which experiments are next on the agenda.

You don’t win over skeptics through obligation, but through benefit. If a developer understands that these colleagues are preventing him from building something that nobody uses, he sees the value. They don’t have to do it themselves, they just have to accept that it’s important.

An internal hackathon brings ideas back from technology

Once developers understand the problem space, it’s worth letting them think for themselves about what features they would implement. A small internal hackathon gives them exactly this space.

The results can be surprising. After such a hackathon, there was strong feedback from customers because problems were solved that were not even in focus and that nobody knew could be solved so quickly. To make something deliverable out of it, rework is needed here and there. The real gain is the return flow: Ideas from technology are fed back into the technical side.