Most agile teams do not have a delivery problem. They have a direction problem. They ship reliably, hit velocity targets, close sprints on time, and still build software that users quietly ignore. Design thinking is the discipline that fixes direction. This guide covers how to actually wire it into an agile software development process: the integration models, the sprint-level mechanics, the roles, the metrics, and the failure modes that sink most attempts.
The short answer: Integrating design thinking with agile software development means running continuous problem discovery in parallel with delivery, not as a phase before it. The dominant implementation is dual-track agile: a discovery track that produces evidence-validated backlog items, and a delivery track that turns them into releasable software. Both tracks share one team, one cadence and one set of outcome metrics. Design thinking decides what is worth building; agile decides how it gets built and shipped.
Why agile alone keeps producing unused software
Agile was a response to a specific failure: long specification cycles that delivered the wrong thing eighteen months late. It succeeded. Teams now release continuously, respond to change, and get feedback in weeks rather than years. But agile is deliberately silent on where backlog items come from. The Agile Manifesto assumes a customer is in the room with well-formed needs. In most organisations that customer is a proxy: a stakeholder, an internal sponsor, a sales escalation. The backlog fills with requests rather than validated problems.
What the evidence actually says
The most-quoted number in this field is that 64% of software features are rarely or never used. It comes from a Jim Johnson keynote at XP 2002 and, as Mike Cohn established when he traced it back to The Standish Group, it was based on a study of just four internal applications. It is directional, not definitive, and most articles citing it have never checked.
The sturdier modern evidence points the same way. Pendo’s 2019 Feature Adoption Report analysed feature usage across 615 subscriptions from customers of more than a year and found that 80% of features in the average software product are rarely or never used. That is waste Pendo valued at up to $29.5 billion in annual public-cloud R&D. McKinsey’s Business Value of Design study found that more than 40% of companies were not talking to their end users during development at all, and just over half had no objective way to assess their design teams’ output.
Two things follow. First, the waste is real regardless of which figure you trust. Second, the root cause is not slow engineering; it is unexamined demand entering the backlog.
What integration is worth
McKinsey found that top-quartile scorers on its Design Index outgrew industry peers by 32 percentage points in revenue growth and 56 percentage points in total returns to shareholders over five years, with results holding across medical technology, consumer goods and retail banking.
At the project level, the Forrester Total Economic Impact study commissioned by IBM modelled a composite enterprise and reported a 75% reduction in initial design and alignment time, a 33% reduction in development and testing time, design defects cut roughly in half, twice the speed to market and a 301% ROI.
Read those numbers honestly. The 301% figure comes from a vendor-commissioned study of a composite organisation, so treat it as a directional signal rather than a forecast. Forrester’s own later, independent research put mature design thinking practices in a more sober 71%–107% ROI range (Forrester, 2019). Quote the conservative number to your CFO. It is still an excellent return, and it will survive scrutiny.
The evidence audit: which design thinking statistics actually hold up
Almost every article on this subject cites the same handful of numbers, and a surprising proportion of them are misattributed, methodologically thin, or both. We traced the nine statistics most commonly used to justify design thinking investment back to their primary sources. Several do not survive the journey.
| Claim as usually cited | Actual primary source | What the method really was | Verdict |
|---|---|---|---|
| 64% of features are rarely or never used | Jim Johnson, Standish Group, XP 2002 keynote | A study of four internal applications. Not from the CHAOS Report, despite constant attribution to it. | Weak: directional at best |
| 80% of features are rarely or never used | Pendo, 2019 Feature Adoption Report | 615 subscriptions, customers of over a year, anonymised usage data. Methodology published. | Strong: vendor data, but disclosed |
| Design thinking delivers 301% ROI | Forrester Total Economic Impact, commissioned by IBM, 2018 | A composite organisation modelled from four client interviews plus 60 surveyed executives. | Moderate: vendor-commissioned |
| Design thinking ROI of 71–107% | Forrester, The ROI of Design Thinking, 2019 | Forrester’s own syndicated research, not commissioned by a vendor. | Stronger: use this one |
| 75% less design time; 33% less dev and test time | Same Forrester TEI study for IBM | Outputs of the composite financial model, not measurements of real projects. | Moderate: model output |
| Design-led firms beat the S&P 500 by 228% | DMI and Motiv Strategies, Design Value Index, frequently misattributed to Adobe | A hand-picked portfolio of 16 companies including Apple, Nike and Disney, 2004–2014. The figure shifts between 228%, 219% and 211% by edition. | Weak: selection bias, avoid |
| 32pp higher revenue growth, 56pp higher TRS | McKinsey, The Business Value of Design, 2018 | Over two million financial data points and 100,000 design actions across 300 companies over five years. | Strong: best available |
| Over 40% of companies never speak to end users | McKinsey, same study | Same dataset and survey base. | Strong |
| 62% of designers say teammates misunderstand discovery | IBM Design, internal survey of designers on agile teams | Self-reported, single organisation, no published sample size. | Moderate: illustrative |
How to use this table. If you are building an internal case, lead with the McKinsey figures and Forrester’s independent 71–107% range. Use Pendo for the waste argument. Avoid the 64% and the 228% entirely unless you state their limitations. Both are widely repeated and both fall apart on inspection, which makes them liabilities in front of a sceptical finance audience rather than assets.
Design thinking vs agile: the distinction that makes integration work
Teams that fail at this integration almost always misdiagnose the relationship. They treat design thinking and agile as competing methodologies and pick a winner, or they assume the two are broadly the same thing wearing different vocabulary. Both readings are wrong.
The cleanest formulation: design thinking is a problem-finding discipline; agile is a problem-solving discipline. They operate on different questions, produce different artefacts, and fail in different ways. That is precisely why they compose well.
| Dimension | Design thinking | Agile software development |
|---|---|---|
| Core question | Are we solving a problem worth solving? | Are we building and shipping it well? |
| Mode | Divergent then convergent | Convergent: decompose, sequence, deliver |
| Primary risk addressed | Value and usability risk | Delivery, quality and schedule risk |
| Unit of work | Assumption, opportunity, hypothesis | User story, task, defect |
| Evidence produced | Interview insight, journey map, tested prototype | Working software, test coverage, telemetry |
| Failure mode | Endless research that never reaches code | Efficient delivery of unwanted features |
| Time horizon | Weeks ahead of the current sprint | The current increment |
A common question worth settling directly: design thinking is not another name for the Agile Manifesto. The Manifesto is a set of four value statements about how software teams should organise and deliver. Design thinking is a human-centred problem-solving methodology with roots in industrial design practice and the Double Diamond, launched by the UK Design Council in 2004. They share a commitment to iteration and to real user feedback. They are not substitutes, and neither contains the other.
Lean sits alongside both as a third lens. Darden’s faculty describe design thinking, lean and agile as complementary I’s of innovation. If you are mapping how these connect at an organisational level, our note on systems thinking for business covers the wider frame.
Four integration models, and how to choose
There is no single correct way to combine these disciplines. There are four patterns that recur, each with a legitimate use case and a characteristic way of going wrong. Pick deliberately.
Model 1: Discovery sprint (front-loaded)
A timeboxed one-to-three week block of research, framing, ideation and prototyping before delivery sprints begin. Sometimes labelled sprint zero or run as a Design Sprint.
- Best for: greenfield products, new market entry, or a genuinely unfamiliar problem space.
- Fails when: it becomes the only discovery that ever happens. Front-loaded discovery is waterfall wearing agile vocabulary.
Model 2: Dual-track agile (the default)
Discovery and delivery run continuously in parallel within one team. The discovery track’s output, validated and de-risked backlog items, becomes the delivery track’s input. This is the pattern most teams should adopt.
Its lineage matters, because it shows this is settled practice rather than a trend: Lynn Miller and Desirée Sy documented parallel-track interaction design at Autodesk in 2005–2007; Jeff Patton and Marty Cagan formalised the term around 2012; Teresa Torres extended it into continuous discovery habits in 2021. Cagan’s account of dual-track agile at SVPG notes he prefers the framing precisely because it captures the parallel nature of the two activities, and because so many teams are otherwise doing little mini-waterfalls inside Scrum.
- Best for: established product teams with ongoing delivery and continuous new-problem intake.
- Fails when: the discovery track quietly becomes a separate upstream team. Then you have reinvented handoffs and called it dual-track.
Model 3: Hybrid sprints (embedded activities)
Design thinking activities are distributed inside the existing sprint structure rather than given their own track: an interview in sprint week one, an assumption-mapping session replacing part of refinement, a prototype test before a story is committed.
- Best for: teams new to design thinking, or teams that cannot yet fund dedicated discovery capacity.
- Fails when: sprint pressure squeezes the discovery activities out first.
Model 4: Scaled integration (SAFe and equivalents)
At programme scale, design thinking is embedded in the planning cadence itself. Discovery findings feed programme increment planning; personas and journey maps become shared programme artefacts.
- Best for: multi-team programmes where divergent user understanding is costly.
- Fails when: discovery becomes a governance artefact, with personas produced for the planning deck and never consulted again.
| If this is true… | Start with | Because |
|---|---|---|
| New product, no existing user research | Discovery sprint, then dual-track | You need a baseline before continuous discovery has anything to iterate on |
| Established product, ongoing roadmap | Dual-track agile | Problem intake is continuous, so discovery must be too |
| No dedicated design or research capacity | Hybrid sprints | Builds the habit before you justify headcount |
| Team is sceptical or has been burned before | Hybrid sprints on one problem | A small visible win beats a process mandate |
| Five or more teams on one solution | Scaled integration | Shared user understanding is the coordination bottleneck |
The sprint-level operating model
This is where most guidance stops and most implementations fail. Below is what actually changes, ceremony by ceremony, when a Scrum team adopts dual-track working. Nothing here requires new meetings; it changes the inputs and exit criteria of meetings you already hold.
| Ceremony | What changes | Exit criterion |
|---|---|---|
| Backlog refinement | Items arrive with evidence attached: the opportunity, the assumption tested, the result. Untested items are tagged as assumptions, not requirements. | No item enters ready without evidence or an explicit recorded bet |
| Sprint planning | Delivery capacity is committed as usual. Separately, 10–15% of capacity is reserved for discovery and made visible on the board. | Discovery work is on the board with names against it |
| Daily stand-up | Discovery blockers surface alongside delivery blockers. Failure to recruit participants is a blocker with the same status as a failing build. | Both tracks reported; impediments to learning treated as first-class |
| Sprint review | Demonstrate learning as well as software: what was tested, what was falsified, what changed. Invite actual users, not only stakeholders. | At least one belief held at sprint start has been updated or confirmed |
| Retrospective | Add one recurring question: what did we build this sprint that we were not confident anyone needed? | Team names its own unvalidated work rather than defending it |
| Continuous (weekly) | At least one direct customer touchpoint per week, involving the trio. | Cadence maintained; findings logged in a searchable repository |
The two backlogs and the Evidence Gate
Dual-track working requires two distinct queues. Collapsing them into one is the single most common structural mistake.
- Discovery backlog: ordered by risk, not value. The top item is whatever assumption would most damage the product if it turned out to be wrong. Items are questions, and they are closed by evidence, not by shipping.
- Delivery backlog: ordered by value and dependency, as normal. Items are stories with acceptance criteria.
The interface between them is what we call the Evidence Gate: an item moves from discovery to delivery only when its riskiest assumption has been tested and the team can state, in a single sentence, what evidence justifies building it. The gate has one legitimate bypass: a deliberate bet, recorded as such, with the person making it named. Bets are fine. Unexamined assumptions dressed as requirements are not.
Work that ships without passing the gate accumulates as discovery debt, the product-management equivalent of technical debt. Like technical debt it compounds quietly, and like technical debt it is eventually paid in rework, dead features and roadmap reversals.
Artefacts worth maintaining
- Assumption map. Every belief underpinning the current roadmap, plotted on two axes: importance, and strength of evidence. The critical-but-unevidenced quadrant is your discovery backlog.
- Opportunity solution tree. Connects a single outcome to the opportunities that could move it, and each opportunity to candidate solutions and experiments. Prevents solution-first drift better than any other artefact.
- Story map. Jeff Patton’s technique for arranging the user journey horizontally and release slices vertically.
- Research repository. Searchable, tagged, and linked from backlog items. Research nobody can find is research nobody did.
If your team is building this discovery muscle from scratch, our guide to the new product discovery process covers the underlying method in more depth, and design thinking for service design extends it to journeys spanning human and digital touchpoints.
Who does what: the product trio
Dual-track agile does not work with a designer bolted onto a delivery team. It works when three perspectives make discovery decisions together.
| Role | Owns in discovery | Owns in delivery |
|---|---|---|
| Product manager | Outcome definition, opportunity prioritisation, business viability | Backlog order, scope decisions, stakeholder alignment |
| Designer | Research design, synthesis, prototyping, usability evidence | Interaction specification, design system consistency |
| Tech lead / engineer | Feasibility assessment, option-shaping, prototype instrumentation | Architecture, implementation, quality |
| Scrum master / delivery lead | Protects discovery capacity from delivery pressure | Flow, ceremony health, impediment removal |
The engineer’s presence in discovery is the part most often cut, and the part that pays for itself fastest. Engineers who hear a user struggle propose different solutions than engineers handed a specification. IBM’s own internal research is blunt about what happens when this is neglected: in a survey of designers on agile teams, 62% reported that teammates did not understand the impact of discovery work on deliverables, and 55% said design was de-prioritised after initial release (IBM Design). Even the organisation that built a 300%-ROI design thinking practice had to fight this internally.
This is fundamentally a psychological safety problem before it is a process problem. Teams only surface disconfirming evidence when it is safe to do so. Our psychological safety learning programmes address exactly this precondition.
Metrics: measure outcomes, not ceremonies
If you keep measuring velocity and story points, you will keep optimising for output, and design thinking will read as overhead that reduces throughput. Because in the short run, it does. The metric set has to change at the same time as the process, or the process will not survive its first quarter.
| Layer | Metric | What it tells you |
|---|---|---|
| Discovery health | Customer touchpoints per week; assumptions tested per sprint | Whether learning is happening at cadence |
| Decision quality | Percentage of delivered items with linked evidence; ideas killed before build | Whether learning is changing decisions |
| Product outcome | Adoption at 30/90 days; task success rate; time-to-first-value | Whether the built thing moved the intended behaviour |
| Efficiency | Rework rate; defect density in user-facing flows; scope reversals | Whether discovery is reducing waste downstream |
| Business | Revenue or cost impact; CLV movement in the target segment | Whether the outcome mattered commercially |
The counter-intuitive one is ideas killed before build. A discovery practice that never stops anything is not doing discovery; it is doing justification. Track it explicitly and celebrate it in review, or the team will learn that the socially safe finding is always yes, proceed. Our piece on increasing customer lifetime value with design thinking connects these measures to commercial outcomes.
Seven failure modes, and how to avoid them
- Design thinking as an event. A workshop generates energy and a wall of sticky notes; nothing changes in the backlog. Countermeasure: no workshop without a named decision it will inform and a date by which that decision is made.
- Sprint zero as disguised waterfall. Discovery is completed up front, then never revisited. Countermeasure: timebox it hard, and schedule the first continuous-discovery touchpoint before it ends.
- The upstream team. Discovery drifts into a separate group handing specifications downstream. Countermeasure: one team, one standup, shared outcome accountability.
- Empathy theatre. Interviews conducted, personas printed, roadmap unchanged. Countermeasure: name what would have to be true for the team to change course before gathering data.
- Designers as ticket-takers. The designer receives stories and produces screens with no mandate to question the problem. Countermeasure: designers co-own the discovery backlog.
- No protected capacity. Discovery is expected to happen as well as a full delivery commitment. It does not. Countermeasure: reserve 10–15%, make it visible, treat raiding it as a process breach.
- Unchanged incentives. Teams still assessed on features shipped per quarter. Countermeasure: change the reporting line before the process. Leadership must ask about outcomes where it used to ask about velocity.
Six of these seven are organisational rather than methodological. That is the honest headline: the integration is not technically difficult, and the barrier is almost always operating rhythm, incentives and leadership attention. This is the territory our business agility learning services and design thinking consulting engagements are built to address.
Design thinking in SAFe: how the scaled framework defines it
A large share of interest in this topic comes from people working inside the Scaled Agile Framework, where design thinking is a named element rather than an optional practice. SAFe defines it as an iterative solution development process ensuring solutions are desired by customers and users while remaining feasible, economically viable and sustainable across the product lifecycle. Those four properties are the framework’s measure of solution success:
- Desirable: do customers and end users actually want the solution?
- Feasible: can we deliver it through some combination of build, buy, partner or acquire?
- Viable: does the solution create more value than it costs?
- Sustainable: are we proactively managing it across its expected product-market lifecycle?
The first three are the classic desirability–feasibility–viability lenses IDEO popularised. Sustainability is SAFe’s addition, and the one most teams skip: it asks not whether you can launch something but whether you can keep it economically alive (SAFe on developing sustainable products). SAFe also positions products and solutions as needing all four simultaneously, and assigns Product Management explicit accountability.
Practically, this changes where discovery sits rather than what it is. Findings feed Planning Interval planning instead of a single team’s sprint planning; personas and journey maps become shared Agile Release Train artefacts; and the Innovation and Planning iteration provides exploration time that single-team Scrum must carve out of capacity. Everything else in this guide (the two backlogs, the Evidence Gate, the trio, the metric set) transfers unchanged.
A 90-day implementation sequence
A realistic path for a single team moving from conventional Scrum to dual-track working. Deliberately narrow: one team, one product area, one outcome.
| Phase | Focus | Concrete steps |
|---|---|---|
| Days 1–30 Establish the baseline | Make current assumptions and waste visible | Run an assumption-mapping session on the existing roadmap; define one measurable product outcome to replace a feature target; audit the last two quarters for actual feature usage; form the trio and book a recurring weekly customer slot |
| Days 31–60 Run the loop | Prove the mechanics on one real problem | Reserve 10–15% capacity in sprint planning; open a discovery backlog ordered by risk; test the top three assumptions with lightweight prototypes; demo learning at sprint review, including a falsified belief |
| Days 61–90 Institutionalise | Convert the pilot into a durable rhythm | Adopt the Evidence Gate between the two backlogs; stand up a searchable research repository linked from stories; switch the reporting metric from output to outcome; retrospect on the integration itself |
Ninety days will not transform an organisation. It will produce one team with a working loop, a documented set of before-and-after numbers, and an internal reference case, which is what makes the second and third teams substantially easier.
Frequently asked questions
Is design thinking compatible with Scrum?
Yes, and it requires no changes to the Scrum framework itself. Discovery work occupies reserved capacity within the sprint; refinement gains an evidence requirement; review demonstrates learning alongside working software. The events, roles and artefacts of Scrum remain intact. What changes is the quality standard for backlog items entering them.
Does adding design thinking slow delivery down?
Short-term throughput usually dips, because 10–15% of capacity moves to discovery. Downstream, the evidence points the other way: the Forrester study for IBM modelled a 33% reduction in development and testing time and roughly half the design defects, because less work is built twice. Expect a quarter of apparent slowdown before rework begins falling.
How much research is enough per sprint?
One meaningful customer touchpoint per week is the widely used benchmark, and it is more useful than volume. Five interviews that change a decision beat fifty that confirm what the team already believed. Judge sufficiency by whether the team’s confidence on a specific assumption actually moved.
Who owns design thinking in an agile team?
Nobody owns it alone. The product manager owns the outcome, the designer owns research and synthesis quality, the engineer owns feasibility, and the delivery lead owns protecting the capacity. If a single person owns it, it becomes their side project and dies when they are busy.
What is the difference between dual-track agile and design thinking?
Design thinking is the methodology: the empathise, define, ideate, prototype and test approach to problem-finding. Dual-track agile is the delivery structure that gives that methodology somewhere to live inside a sprint cadence. You use dual-track agile to run design thinking continuously rather than as a project phase.
Can this work with distributed or offshore teams?
Yes, with two adjustments: customer sessions must be recorded and shared asynchronously so the whole team has access to raw evidence rather than summaries, and the research repository becomes essential rather than optional. Distributed teams fail at this when insight lives only in the heads of whoever attended the call.
What does the academic literature say?
A systematic literature review published in Procedia Computer Science examined 29 studies on design thinking integrated with agile software development and found most integrated models apply across the whole software lifecycle rather than a single phase, with the ISO-published design thinking approach combined with Scrum being the most frequently used pairing. Corral and Fronza’s ACM paper on design thinking and agile practices reaches compatible conclusions: benefits in user-centricity and cycle time, with cultural and process friction as the recurring obstacle.
Where to start
If you take one thing from this guide, take the Evidence Gate: nothing enters the delivery backlog without either supporting evidence or an explicitly recorded decision to bet without it. That single constraint forces every other part of the practice into existence. You cannot satisfy it without discovery capacity, without someone doing research, without a place to record findings, or without a team willing to say we do not know yet.
Start there, on one team, with one outcome. Then measure what you stop building.
Humane Design helps product and engineering organisations build discovery capability that survives contact with a delivery calendar. Explore our business agility learning services, product management programmes, and design thinking consulting. Or see how we delivered improved UX for a SaaS platform and our wider case studies.
