Scrum works for non-software teams, with one condition: the work has to be complex enough to need a plan and uncertain enough that the plan will be wrong. That describes a lot of operations work. It does not describe all of it, and the teams that fail with scrum usually failed that test before they started.
Scrum itself is deliberately thin. It is a framework for working in short, fixed cycles with a small cross-functional team, reviewing the result each cycle and adjusting (Scrum Guide). Nothing in that definition mentions code. The reason it reads as a software method is that software teams wrote all the examples.
This post is the translation for a business that ships physical goods: what each role becomes, what a sprint contains when your output is orders rather than features, and the specific points at which the framework stops helping. For the wider question of running an operation iteratively, agile methodology in logistics covers the strategy; this is the framework underneath it.
The Bottom Line
- Scrum transfers outside software. In the 2025 State of Agile data, 28% of business operations teams reported using agile practices (State of Agile 2025, via KnowledgeHut).
- Use it for improvement projects with a definable goal, not for daily order flow. Continuous, interrupt-driven work belongs on a kanban board instead.
- Budget four to six hours per person per two-week sprint for the ceremonies. If the work is not worth that, scrum is not worth it.
- The role that decides priorities is the one you cannot skip. Everything else can be adapted.
Lower your delivery costs by 23%
How we reduce costs:
- No delivery vehicle expenses
- Optimized local routes
- Pay-per-delivery model
- Average 23% delivery cost reduction
Does scrum work outside software development?
Yes, where the work is complex and iterative rather than repetitive.
The Scrum Guide describes the framework in terms of complex problems and incremental delivery, and never limits it to software. Published accounts cover medical centers reducing readmission rates, marketing agencies running campaign delivery, and HR and sales departments working in sprints (Agile Alliance experience reports).
What those cases share is not their industry. It is that the work was a project with an unclear path, something the team had not done exactly this way before, where the second week’s plan would sensibly differ from the first week’s.
The useful inversion is knowing where it does not apply. Scrum adds little to work that is repetitive and well understood. Picking twelve wholesale orders on Tuesday is not a complex problem requiring inspection and adaptation; it is a process requiring flow. Running that on sprints adds ceremony and removes nothing.
Non-technical teams also adapt the artifacts more physically than software teams do. Sprint backlogs go on windows and whiteboards, planning happens around flipcharts, and the digital tooling is often skipped entirely. That is not a degraded version of scrum. For a team already in one building, it is the better one.
What the three scrum roles become in an operations team
Scrum names three accountabilities. All three exist in your business already, usually without the labels.
Product owner → the person who decides what gets worked on. They own the backlog, set the order, and can say no. In a small business this is usually the owner or the operations manager. This is the role you cannot merge away: without one person deciding priority, a sprint becomes whatever the loudest customer asked for on Tuesday.
Scrum master → the person who runs the cadence and clears blockers. Not a manager, and not necessarily a hire. They keep the meetings short, make sure the sprint goal stays in view, and chase the things stopping the team. A supervisor can do this in a few hours a week. The trap is combining it with the product owner role, which removes the tension the two are supposed to hold.
Developers → whoever does the work. In an operations sprint that is your pickers, packers, dispatch coordinator and possibly someone from customer service. “Cross-functional” here means the team contains everyone needed to finish the goal without waiting on another department. If every sprint stalls pending a decision from someone outside the room, that person belongs in the team.
Keep the team small. Scrum caps it around ten people for a reason, and operations sprints work best at four to seven.
What a sprint is when your product is orders going out the door
A sprint is a fixed time window with one goal and a short list of work that serves it. One or two weeks suits operations; four is too long to hold a goal in a business where next month’s problems are unknowable.
The critical translation is the sprint goal. In software the increment is working product. In an operations team it is a demonstrable improvement to how the work runs. Real examples:
- “Cut the time between order received and order picked to under four hours for all wholesale accounts.”
- “Get the new cold-chain packing process running on every route, with drivers trained on it.”
- “Onboard the two new catering accounts, including their delivery windows and access instructions.”
Each of those can be shown to somebody at the end of two weeks and judged done or not done. That is the bar. “Improve efficiency” fails it, and a sprint goal that cannot be judged is how teams end up two months in with a full board and no result.
The other rule is that daily order fulfillment does not go in the sprint backlog. It continues regardless, because it is the baseline work, and putting it in a sprint means every sprint succeeds by definition. Sprint capacity is whatever is left after the orders go out, which in practice is often one or two days a week across the team. Plan for that honestly and the sprints will finish.
The four scrum ceremonies and what they cost
Scrum prescribes four recurring events. Here is each one at two-week sprint length for an operations team.
| Ceremony | When | Length | The question it answers |
|---|---|---|---|
| Sprint planning | First morning | 60–90 min | What is the goal, and what work serves it? |
| Daily scrum | Every morning | 10–15 min | What is blocking us today? |
| Sprint review | Last afternoon | 30–45 min | What actually changed, and what do stakeholders think? |
| Retrospective | Last afternoon | 30 min | How do we work better next sprint? |
That totals roughly four to six hours per person per sprint, and knowing the number in advance matters. Teams adopt scrum, absorb the meeting load without accounting for it, and conclude after a month that scrum slowed them down. It did. The question is whether the decisions it produced were worth the hours, which is only answerable if you knew the cost going in.
Two notes from practice. The daily scrum is not a status report to a manager; it is the team telling each other what is in the way, and it collapses into a progress meeting the moment a manager starts taking notes. And the retrospective is the ceremony most often cut when the team is busy, which is exactly backwards, because it is the only one whose output is a change to how you work.
How to build a backlog for an operations team
The backlog is an ordered list of things worth doing, not a task dump. Three sources fill it well.
What went wrong recently. Failed deliveries, late orders, damaged goods, complaints. Tally causes for a month before prioritizing, because the loudest incident is rarely the most expensive pattern. Attaching a cost to each category helps the ordering: a failed delivery attempt averages around $17.78 across the industry, and address errors account for roughly 45% of them (ClickPost’s last-mile delivery statistics).
What people work around. Every operation has a workaround: the spreadsheet somebody maintains by hand, the call that has to be made before every delivery to a particular account. Workarounds are backlog items with the cost already proven.
What growth will break. The process that works at forty orders a day and will not survive eighty. These are the items nobody raises, because they are not problems yet.
Order the list by cost times frequency, and keep it visible. One discipline makes the difference: the backlog is ordered, not grouped by priority band. If two items are both “high”, one is still going first, and deciding which is the product owner’s job.
Scrum or kanban for operations work?
Short version: kanban for the flow, scrum for the projects.
Kanban for order fulfillment governs the continuous daily work, meaning orders moving through picking, packing and dispatch, with limits on how much can be in each stage. No sprints, no new roles, low meeting cost. It is the right default for anything where the day is dictated by what arrives.
Scrum governs bounded improvement work: a goal, a team, a protected two weeks. Running both is normal, and most operations end up there: a board on the wall for today’s orders, a sprint in the background for the thing that keeps going wrong.
If the underlying question is whether a new service should exist at all rather than how to build it, neither framework answers it. The Lean Startup method is what tests demand before you commit capacity to it.
Where scrum breaks in a non-software team
The sprint gets interrupted every time. A large customer calls, the sprint work stops, nothing finishes for six weeks running. Either the team gets protection for part of its capacity, or the work belongs on a kanban board where interruption is expected.
The product owner will not prioritize. Everything is important, the backlog is unordered, and the team picks whatever seems urgent. This is the failure mode that looks most like scrum while being least like it.
Ceremonies without decisions. Four meetings per sprint that change nothing are pure cost. If two retrospectives pass with no change to how the team works, stop and ask why people are not raising real problems.
Forcing routine work into sprints. Daily fulfillment does not benefit from being estimated, committed to and reviewed. It benefits from flow.
Adopting the vocabulary and not the loop. Calling the weekly meeting a “standup” and the to-do list a “backlog” while nothing about the cadence or the review has changed. Harmless, but it makes the team believe they tried scrum when they did not.
Frequently Asked Questions
Can scrum be applied to teams that do not develop software?
Yes. Scrum is deliberately domain-neutral. It describes a cadence, three accountabilities and four events, none of which are software-specific (Scrum Guide). Published cases cover healthcare, marketing, HR and sales teams. What has to be true is that the work is complex and benefits from frequent inspection, rather than being repetitive and well understood.
Do we need a certified scrum master?
No. Certification helps someone run the meetings well, but the job is keeping meetings short, keeping the goal visible and removing blockers. A capable supervisor with the Scrum Guide and a few hours a week can do it. What does not work is nobody holding the role, because then the ceremonies drift and the framework dissolves without anyone deciding to drop it.
How long should an operations sprint be?
One or two weeks. Two is the common choice: long enough to finish something meaningful, short enough that a wrong plan costs ten working days rather than a month. Once chosen, keep the length fixed, because variable sprints make it impossible to compare one to the next.
What if we cannot commit the whole team to a sprint?
Normal, and workable. Commit a share of capacity instead, one day a week each say, and size the sprint goal to that share. Overcommitting is the more common failure: teams plan as if orders will not need packing, then miss the goal and blame the framework.
Is scrum overkill for a five-person business?
Often, yes, for daily work. It is not overkill for a defined project with an unclear path, like launching a new delivery service or reworking your packing process. Small teams should also strip it down: keep planning, a short daily check and a retrospective, and drop the formal review if the only stakeholder is already in the room.
Running the first sprint
Pick one problem worth two weeks. Write it as a goal someone could judge done or not done on a specific Friday. Name the person who decides priority and the person who runs the cadence. List the work that serves the goal, cut it by half, then start.
At the end, hold the retrospective even if the sprint failed, especially then. One sprint tells you almost nothing about whether scrum suits your team. Three tells you plenty, and by then you will also know whether the friction you keep hitting is internal or on the customer’s side, which is a different problem and needs design thinking for customer experience rather than a tighter sprint.
