The most common objection we hear isn’t about price. It’s time: “our team can’t spare a week right now.” It’s a fair worry, and it’s almost always based on an overestimate of what a sprint actually asks of the people already stretched thinest.
Here’s the honest client-hour accounting, phase by phase, for a typical two-week sprint with one embedded team.
Discover (days 1–3): roughly 3–4 hours per person, spread out. This is observation and conversation: a couple of short sessions with the PI or programme lead, one or two sessions with whoever does the actual day-to-day work the idea touches, and access to whatever documents or systems already exist. We come to your team’s normal meetings rather than asking them to come to ours. No prep required beyond showing up as you already would.
Define (days 3–5): one working session, about 90 minutes, with the smallest group that can make a call. This is the step where we converge on the one problem worth solving and name who has the authority to decide. It only works with the right two or three people in the room, not a large committee, which is one reason it’s shorter than people expect.
Develop (days 6–9): light-touch check-ins, 30–45 minutes every day or two. We’re sketching and testing directions on our side. Your team’s job here is mostly reacting to what we bring back: quick reads on “does this feel right,” not new work.
Deliver (days 10–14): one real testing session, 1–2 hours, plus a closing readout, about an hour. The testing session is with the people who’d actually use the thing, not just leadership. This is often the first time in the sprint your frontline staff are directly involved, and it’s usually the part people find most energising rather than most costly.
Total: somewhere between 8 and 12 hours of client time, across two weeks, spread across several different people rather than concentrated in one. No single person on your team spends more than a working day’s worth of hours on the whole sprint. What we’re asking for is attention in short bursts, at the right moments, not availability.
What this buys back. The alternative most research teams are actually choosing between isn’t “sprint versus no time cost.” It’s “two weeks of light engagement now” versus “months of a project moving on assumptions nobody tested, discovered later, usually by whoever inherits the unfinished build.” The sprint is not additional work stacked on top of the real work. It’s the fastest way to find out whether the real work is worth doing at all.
If the honest number above is still more than your team can spare right now, that’s useful to know too. It usually means the timing is wrong, not that the method is.