UX in agile teams: Scrum and Kanban without losing design

In Scrum and Kanban, design often falls behind or arrives late. What the 2020 Scrum Guide, NN/g and Scrum.org say, and how to integrate discovery and delivery.

info Quick Definition
In an agile team, design has two jobs that sometimes clash: deciding what to build (research, prototypes, tests) and helping build it well (interaction decisions, acceptance criteria, review). The sprint pushes toward delivery while discovery needs time. Integrating both without losing either is the central problem of UX in agile.

Why does design often fall behind in Scrum?

Because the sprint has a fixed rhythm and design has a variable one. A user test can take a week to organize, and the analysis may reveal that the idea does not work. If the development team waits for design, it loses time. If design runs ahead without contact with the team, work gets produced that is never implemented.

NN/g (Anna Kaley, 2023), in its video on discovery in agile, asks that discovery activities be scaled rather than skipped, even when sprints are short. The idea is to plan them around targeted questions and probable assumptions, not arbitrary sprint timeframes.

What does the 2020 Scrum Guide say?

The Scrum Guide does not mention design or UX, but its rules set the ground:

  • The team is cross-functional. Its members have all the skills needed to create value each sprint, and within the team there are no sub-teams or hierarchies.
  • Developers are whoever creates any aspect of the Increment. The guide defines them as the people committed to creating “any aspect of a usable Increment” each sprint. It is a reasonable reading that design work belongs here, but the guide does not say so explicitly.
  • The Increment must be usable and meet the Definition of Done.
  • A sprint lasts one month or less.

This is the case against a separate “design team” that hands work to the development team. The Agile Manifesto points the same way in its fourth principle: business people and developers must work together daily throughout the project.

What is the risk of a one-sprint offset?

Scrum.org (Alex Ballarin Latre, 2024) analyses the model in which design defines the interface in sprint N, development builds it in N+1 and design tests it in N+2. Its critique is direct: it is not Scrum, because at the end of the sprint there is no potentially deliverable product; delivery is delayed by three sprint cycles; and almost all the interaction between user, designer and developer is lost.

Jeff Gothelf (2018) reaches a similar conclusion: if design happens outside the team, with an in-house or external designer, the team falls back into Big Design Up Front and loses collaboration, shared understanding and trust. He recommends a full-time designer inside the Scrum team.

That does not mean all discovery must fit in the same sprint as construction. It means the conversation between design and development cannot be broken.

What is dual-track, and how is it different?

Dual-track agile separates the work into two tracks that run in parallel. The discovery track produces, tests and validates product ideas before committing to build them. The delivery track turns the validated ideas into product. According to Productboard, the idea first appears in writing in 2005 with Lynn Miller, Desirée Sy raises it again in 2007, and in 2012 Marty Cagan and Jeff Patton discuss dual-track scrum.

Its appeal is clear: design works on what comes next and development on what is ready. The risk is that it becomes two teams passing work between them, which is exactly the offset above. Scrum.org points out that Sy’s original idea involved frequent collaboration between designers and developers, not separate sprints. The details of the model are in dual-track agile; Lean UX raises the same tension from the angle of hypotheses and experiments, and continuous discovery proposes the weekly habit of talking to users.

How does it fit into Scrum?

Scrum.org proposes putting designers and developers in the same sprint, working in parallel: design arrives before development needs the screen, but not so far ahead that it loses contact. These practices help and fit the UX design process the team already uses:

  • Continuous discovery. Small weekly tests with concrete questions, instead of one large study at the start. Gothelf adds that activities such as design sprints, qualitative research and hypothesis writing keep the backlog grounded in customer reality.
  • Design in planning. Collaborative sketching and group brainstorming in sprint planning help answer questions about screen flows and exceptions.
  • Design in acceptance criteria. States, error messages and behaviours included in each story, so development does not have to guess.
  • Joint review. In the sprint review, design reviews, research synthesis and analytics inform what gets released and what is prioritized next.
  • Up-front big-picture work. Warren Croce, quoted by UXmatters, argues for a discovery “Sprint 0” before development. It is a community practice, not part of the Scrum Guide; if you use it, keep it short and in contact with the team.

Adrian Howard, quoted in the same UXmatters discussion, says the agile cadence lets him fit generative and evaluative research into the team’s cycles.

And Kanban?

Kanban has no sprints, so design does not need a formal offset. What it needs is visibility: discovery should appear on the board with its states, for example “to research”, “in test” and “validated”. This is a proposal of this article, not a Kanban rule: treat discovery as a flow of its own with work-in-progress limits, so untested hypotheses do not pile up.

Example

Illustrative example: a team building a health app works in Scrum with two-week sprints, and the designer is part of the team. In the first sprint the stories are small, and the designer uses the first week to interview five patients and test a paper prototype while development prepares the technical base. In the following sprints, each story arrives with its design criteria: loading states, error messages and keyboard navigation. Every week, the designer tests the version built the previous week with two people. Development does not wait for design, and design does not work in a vacuum.

For your team: review the last three user stories. If any arrived without visual or interaction criteria, ask for them to be reviewed before the next sprint.

When should you NOT use this approach?

  • When the team is so small that one person does both design and development. Separating tracks adds nothing.
  • When the product has no accessible users for discovery. Without them, discovery becomes assumptions.
  • When the team uses agile only as a label and decisions are made by one person outside the cycle.

Common mistakes

  • Designing one sprint ahead without contact with the development team.
  • Treating discovery as a phase that ends before construction begins.
  • Leaving stories without design criteria.
  • Excluding design from planning because it is not considered “real work”.
  • Measuring design by deliverables rather than user outcomes.
  • Running discovery without reviewing what was actually built.

Sources

Frequently asked questions

Where should design sit in a Scrum team?
Inside the team, not outside it. The 2020 Scrum Guide says the team is cross-functional with no sub-teams, and Scrum.org criticizes the model in which design works one sprint ahead because it delays delivery and breaks the conversation between user, designer and developer.
What is dual-track agile?
A model with two tracks: discovery, where product ideas are produced, tested and validated, and delivery, where what has been validated is built. Productboard describes it this way and dates its spread as dual-track scrum to 2012, with Marty Cagan and Jeff Patton.
Can design work in Kanban?
Yes. Kanban has no sprints, so the challenge is visibility. One practical proposal is to show discovery as a flow of its own on the board, with states such as ’to research’, ‘in test’ and ‘validated’, and with work-in-progress limits.
What happens if design runs one sprint ahead?
According to Scrum.org, at the end of the sprint there is no potentially deliverable product, delivery is delayed by three sprint cycles, and almost all the interaction between user, designer and developer is lost.