Agile works for non-software teams when you keep the parts that create feedback (short timeboxes, a visible prioritized backlog, a clear definition of done, and a regular retrospective) and drop or rework the parts that assume code (velocity as a contract, "potentially shippable increments" every two weeks, story points for every task). Finance, HR, and marketing teams get the most value by applying sprints to improvement and project work while routing recurring operational work through a Kanban lane.
This guide covers what transfers and what doesn't, then walks through finance and accounting, HR and people operations, and marketing, each with a sample sprint backlog, what "done" means, and how estimation works when the work isn't software. For a shorter overview, see the agile for non-software teams page.
What transfers from software agile, and what doesn't
Most failed agile rollouts outside engineering copy the Scrum ceremonies verbatim and then wonder why the accounts payable clerk is being asked for story points on invoice batches. Start with this table instead.
| Practice | Transfers? | How to adapt it |
|---|---|---|
| Timeboxed sprints (1–3 weeks) | Yes, for project and improvement work | Align sprint boundaries with your natural calendar (month-end, pay cycles, campaign launches) |
| Prioritized backlog | Yes, fully | One visible list, one person who owns the order |
| Daily standup | Partly | 10 minutes, blockers only. Skip it on days with nothing coordinated |
| Sprint review / demo | Yes | Show the actual artifact (the reconciled schedule, the revised offer letter, the landing page) to the people who consume it |
| Retrospective | Yes, and it's the highest-value practice | Run it after every cycle, even when busy |
| Story points | Selectively | Use for uncertain, non-repeating work. Don't point recurring tasks with known durations |
| Velocity | Rarely | Useful only if the team's work mix is stable. Don't use it to compare people or teams |
| Definition of Done | Yes, critical | Usually includes a review/approval step and a compliance check that software teams don't have |
| "Shippable increment" each sprint | Loosely | Replace with "something a stakeholder can react to" |
| Product Owner role | Yes, renamed | Often the controller, HR business partner, or marketing lead who owns priorities |
Two things don't transfer at all:
- Fixed external deadlines don't move. Tax filings, payroll cutoffs, statutory reporting, benefits open enrollment, and a trade show date are not negotiable in sprint planning. Treat them as fixed dates on the calendar and plan sprints backward from them.
- Controls and approvals aren't "waste." A software team might cut a review step to go faster. In finance and HR, segregation of duties and legal review are the point. Put them inside your definition of done instead of fighting them.
Sprints for projects, Kanban for flow
Almost every non-software team has two kinds of work:
- Flow work: recurring, predictable, often deadline-driven. Invoice processing, payroll runs, candidate screening, social posting, publishing the newsletter.
- Project and improvement work: one-off, uncertain, benefits from timeboxing. Automating a reconciliation, redesigning onboarding, launching a campaign.
Put flow work on a Kanban board with work-in-progress (WIP) limits. Put project work into sprints. Reserve a fixed share of capacity for each (for example, 70% flow and 30% sprint work) and protect the sprint share. If you skip this split, flow work eats the sprint every time and the team concludes "agile doesn't work here."
How estimation works for non-software work
Estimation outside software is less about forecasting velocity and more about surfacing disagreement about scope early. When the payroll specialist says "2" and the HR generalist says "13" on "update the remote work policy," you've found out that one of them knows about the multi-state tax implications and the other doesn't. That conversation is the value.
Practical rules:
- Don't estimate recurring work. If month-end bank reconciliations take about a day every month, write "1 day" and move on. Estimation is for things you haven't done in this exact form before.
- Use T-shirt sizes for early-stage work. Marketing and HR teams usually find XS–XL easier to agree on than numbers. See Fibonacci vs. T-shirt sizing for when each fits.
- Build a reference set. Pick three completed items your team agrees on (one small, one medium, one large) and compare new items to them.
- Vote simultaneously. Seniority bias is often stronger in finance and HR hierarchies than on engineering teams. Hidden votes revealed at once keep the controller's or director's number from anchoring everyone else.
- Capture confidence, not just size. A "5, but I'm not sure" is different from a confident 5. Low confidence usually means the item needs a discovery task first.
The guide to estimation for non-technical teams goes deeper on choosing a scale and calibrating it.
Agile for finance and accounting teams
Finance has a built-in sprint: the close. The month already has a hard start, a hard end, a list of tasks, and a review step. Agile accounting doesn't replace the close calendar; it makes the close visible, finds the bottlenecks, and uses the time between closes for improvement work.
Month-end close as a sprint: an example
Here is a hypothetical 6-person accounting team that closes in 8 business days and wants to get to 6.
| Day | Close focus | Sprint mechanics |
|---|---|---|
| Day -3 to -1 | Pre-close: accrual estimates, cutoff reminders to departments, open PO review | Sprint planning: confirm owners, flag known risks from last retro |
| Day 1–2 | Cash and bank reconciliations, AP/AR cutoff, payroll entries | 10-minute daily standup: "What's blocked, who needs what" |
| Day 3–4 | Accruals, prepaid amortization, revenue recognition, intercompany | Standup continues; controller reviews entries as they're posted, not in a batch |
| Day 5 | Fixed assets, inventory adjustments, flux review | Preliminary P&L to CFO |
| Day 6–7 | Variance analysis, management reporting package | Sprint review with business partners: walk through variances |
| Day 8 | Final review and lock | |
| Day 9 or 10 | 30-minute retrospective. One improvement goes into next month's backlog |
Between closes, the team works a separate improvement sprint (for example, two weeks in the middle of the month) on items from the retro.
Sample finance sprint backlog (improvement sprint)
| Item | Size | Notes |
|---|---|---|
| Template the recurring prepaid amortization schedule so it rolls forward automatically | S | Came from last retro: 3 hours of manual rework each month |
| Agree a cutoff calendar with marketing so campaign invoices arrive by Day 2 | M | Marketing reclasses caused three late adjustments last close |
| Document the accrual methodology for the new hire onboarding packet | S | |
| Move intercompany reconciliation from Day 4 to pre-close by agreeing balances with the subsidiary on Day -1 | L | Needs the subsidiary controller's buy-in; high uncertainty |
| Build a draft flux commentary template for department heads | M | Stakeholder story: "As a department head, I need variance explanations by Day 6 so I can adjust my forecast" |
Notice that routine close tasks are not in this backlog. They live on the close checklist and the Kanban board.
What "done" means in accounting
A finance item is done when:
- The entry is posted and the account is reconciled in the ERP
- Supporting documentation is attached where an auditor would look for it
- Review and approval are complete by someone other than the preparer
- Any impact on management reporting is reflected
- For process changes: the close checklist and desk procedures are updated
Agile in accounts payable and audit prep
- AP Kanban: Received → Validated → Approved → Scheduled → Paid, with a WIP limit on "Approved" so payment runs don't pile up. When a column hits its limit, the team swarms to clear it before pulling new invoices.
- Audit readiness: Break annual audit prep into quarterly pieces (Q1 policy updates, Q2 control testing, Q3 evidence collection, Q4 final review). Treat prior-year audit findings as backlog items prioritized by risk.
Common mistakes in agile accounting
| Mistake | Fix |
|---|---|
| Story-pointing every journal entry | Only estimate improvement items. Recurring tasks get a duration on the checklist |
| Standups that become status recitals | Use the close tracker for status; standup covers only blockers and handoffs |
| Skipping the retro because close was painful | That's exactly the close you need to retro. Keep it to 30 minutes |
| Treating regulatory deadlines as negotiable | Plan backward from fixed dates; flex only internal reporting |
Agile for HR and people operations
HR has less natural cadence than finance, and more stakeholders: employees, managers, legal, finance, leadership. Agile HR works best when the backlog makes those competing requests visible and someone owns the order.
Agile portfolio management in HR
"Agile portfolio management in HR" usually means managing the whole set of people initiatives (hiring plans, policy changes, programs, systems) as one prioritized portfolio instead of separate annual projects. In practice:
- One HR portfolio backlog holds every initiative above a certain size: new performance cycle, benefits renewal, HRIS migration, onboarding redesign, DEI program, manager training.
- Quarterly prioritization with leadership: rank initiatives by business impact, legal/compliance necessity, and effort. Compliance-driven items go first by default.
- Limit initiatives in progress. An HR team of five running nine programs at once finishes none of them on time. Cap active initiatives (for example, three) and finish before starting.
- Sprints within initiatives. Each active initiative is broken into 2–3 week sprints with reviewable outputs.
- Kanban for service work. Employee questions, offer letters, and benefits changes flow through a service queue that doesn't get story points.
Sample HR sprint backlog (onboarding redesign, sprint 1 of 3)
| Item | Size | Done means |
|---|---|---|
| Map the current new-hire journey from offer accept to day 30, with pain points from the last 3 cohorts | M | Journey map reviewed with two hiring managers |
| Pre-boarding checklist: laptop, accounts, and first-week calendar sent before day 1 | S | IT confirms they can meet the lead time |
| Day-one agenda template for managers | S | Piloted with one team |
| Rewrite the remote work section of the handbook | L | Legal reviewed; multi-state implications confirmed with payroll |
| 30-day new hire pulse survey (3 questions) | S | Survey live; results route to HR and the manager |
User story framing helps keep HR work grounded in the people affected: "As a new hire, I want my accounts working on day one so I can start contributing in my first week" is easier to prioritize than "IT onboarding improvements."
What "done" means in HR
- Legal or compliance review completed where policy or employment terms are touched
- Change communicated to the people affected, not just published on the intranet
- Managers who must deliver it have been briefed
- A feedback mechanism exists (survey, check-in, or named owner for questions)
- Data privacy confirmed: no individual employee data in shared sprint boards or retro notes
Agile recruiting
Recruiting maps well to Kanban: Sourced → Screened → Interviewing → Offer → Accepted, with WIP limits on the stages that depend on hiring managers. Run weekly sprints for the improvement side: a better job description, a structured interview scorecard, a faster scheduling process. In the standup, the most useful question is "which candidates are waiting on someone?" because hiring-manager delays are a common reason candidates drop out.
Common mistakes in agile HR
- Sharing individual feedback in retros or reviews. Aggregate everything. The board should never reveal who complained about which manager.
- Iterating policies too fast. Employees need stability in policy. Pilot changes with one volunteer team, then roll out once.
- Replacing annual reviews with "continuous feedback" and no structure. If you move to quarterly check-ins, give managers a short template and a calendar reminder.
Agile for marketing teams
Marketing is the non-software function where agile is most established, partly because campaigns already behave like experiments. The marketing sprint process that works for most teams looks like this:
A practical marketing sprint process (2-week sprint)
| When | Meeting | Length | Output |
|---|---|---|---|
| Day 1 | Sprint planning | 60–90 min | Sprint goal written as a hypothesis, committed backlog |
| Daily | Standup | 10 min | Blockers, review handoffs, approvals needed |
| Mid-sprint | Backlog refinement | 30–45 min | Next sprint's top items have briefs and owners |
| Day 10 | Sprint review | 30–45 min | Demo of shipped assets plus early performance data |
| Day 10 | Retrospective | 30 min | 1–3 process changes for next sprint |
Write sprint goals as hypotheses: "We believe that a shorter demo-request form will increase landing page conversion for paid search traffic." That keeps the team focused on outcomes rather than counting assets shipped.
Prioritize with ICE. Score each backlog item 1–10 on Impact, Confidence, and Ease, then average or multiply. It's quick, and its main value is forcing a conversation about the confidence score.
Sample marketing sprint backlog
| Item | Size | Done means |
|---|---|---|
| New landing page variant for the demo-request A/B test | M | Live, tracking verified, test running with a pre-agreed sample size |
| Three ad creative variants for the retargeting campaign | M | Approved by brand, uploaded, UTM-tagged |
| Customer case study draft (interview already done) | L | Customer approved the quote; legal cleared logo use |
| Refresh top 5 underperforming blog posts' titles and meta descriptions | S | Published; baseline click data recorded |
| Email nurture: rewrite email 2 subject line, 3 variants | XS | Variants scheduled in the email platform |
Ongoing work (social posting, community management, newsletter production) goes on a Kanban board with its own WIP limit, not in the sprint.
What "done" means in marketing
- Copy reviewed by brand and, where needed, legal/compliance
- Tracking implemented and tested (pixels, UTMs, events firing)
- Asset stored in the shared library with tags
- Success metric and baseline recorded so the next review can report a result
- Launched, not just "approved and waiting"
Running a marketing brainstorm without groupthink
Marketing brainstorms often fall into the same traps that ruin estimation sessions: the first idea anchors everyone (Kahneman and Tversky's anchoring effect), junior people defer to the most senior person in the room, and while one person talks the others lose their own ideas. Agile teams solved a version of this with planning poker: think privately, reveal simultaneously, then discuss. The same structure works for ideation.
A 60-minute anti-groupthink brainstorm:
| Time | Step | Facilitator script |
|---|---|---|
| 0:00–0:05 | Warm-up | "Quick round: what's one campaign from another brand you wish we'd made?" |
| 0:05–0:10 | Frame the problem | "We're not brainstorming 'Q3 campaigns.' We're answering: how might we reach operations leaders who ignore our ads?" |
| 0:10–0:20 | Silent ideation | "Ten minutes, no talking. Write at least three ideas each, one per sticky note or card." |
| 0:20–0:30 | Share and cluster | "I'll read them out without names. We're only grouping similar ones, not judging yet." |
| 0:30–0:35 | Dot vote | "Everyone gets three votes. Put them anywhere, including all three on one idea. We'll reveal at the same time." |
| 0:35–0:55 | Build on the top 3 | "For each one: what makes it promising, and what would make it stronger?" |
| 0:55–1:00 | Confidence check and owners | "On a scale of 1 to 5, how confident are you this direction will work? Show fingers on three." |
Other techniques worth having in your kit:
- Collect ideas before the meeting via a form when a senior leader tends to dominate. The ideas arrive without names and without the leader's framing.
- Reverse brainstorming: "How could we guarantee zero signups from this campaign?" Then invert the answers.
- Pre-mortem (Gary Klein's technique): before committing, ask everyone to write down why the campaign failed, imagining it's six months from now. Doubts that people were too polite to raise come out.
- Rotating devil's advocate: assign the role so dissent is structural, not personal.
- Don't override the vote quietly. If leadership picks an idea that lost the dot vote, explain why openly. Otherwise people stop investing in the process.
If the confidence check comes back low or widely spread, that's a signal to run a small test before committing budget. A quick sprint-confidence vote is also how many teams close their sprint planning; the confidence voting guide explains how to read the results.
A realistic first 30 days
Week 1: Pick one team and one type of work (the close improvement backlog, the onboarding redesign, or one campaign type). Split flow work from project work. Build the backlog and a reference set for sizing.
Week 2–3: Run the first sprint. Daily 10-minute standup, a sprint review with the people who'll use the output.
Week 4: Retrospective. Change one thing. Decide whether sprint length fits your calendar; finance teams often settle on sprints aligned to the close, marketing on two weeks, HR on two or three.
If your team estimates together remotely, Alignlee is a free planning poker tool with no signup. Its T-shirt deck works well for non-software sizing, votes stay hidden until reveal, and each vote carries a confidence slider so uncertain items stand out.
FAQ
Can agile work for non-software teams?
Yes, if you adapt it rather than copy Scrum verbatim. Short timeboxes, a visible backlog, a clear definition of done, and regular retrospectives work in almost any team. Velocity tracking and story-pointing every task usually don't, so use sprints for project and improvement work and Kanban for recurring operational work.
How do you apply agile in non-software projects with fixed deadlines?
Treat external deadlines (tax filings, payroll cutoffs, event dates) as fixed and plan sprints backward from them. Agile then helps you get ready earlier and see risk sooner, rather than making the deadline flexible. Scope, not date, is what you adjust inside the sprint.
What is agile accounting?
Agile accounting applies sprints, backlogs, standups, and retrospectives to finance work, most often by treating the month-end close as a timeboxed cycle and running improvement sprints between closes. Controls, review steps, and segregation of duties stay in place; they become part of the definition of done.
What is agile portfolio management in HR?
It means managing all HR initiatives as one prioritized portfolio, reviewed quarterly with leadership, with a cap on how many run at once. Each active initiative is delivered in short sprints with reviewable outputs, while day-to-day HR service requests flow through a separate Kanban queue.
What does a marketing sprint planning meeting look like?
A 60–90 minute session where the team agrees a sprint goal written as a hypothesis, pulls the highest-priority backlog items that fit capacity, and confirms each item has a brief, an owner, and a definition of done. Recurring work like social posting stays on a separate board so it doesn't crowd out the sprint goal.