5 Agile Frameworks: Scrum in HR

Learning Objectives

You will be able to:

Explain the origins of Scrum and the purpose of its roles, artifacts, and events.
Translate each Scrum element into an HR equivalent: the HR product owner, the people backlog, and the HR sprint.
Plan and run a multi-sprint HR project, from backlog creation through sprint review and retrospective.
Judge which kinds of HR work suit Scrum and which are better served by flow-based methods such as Kanban.

5.1 Introduction

Chapter 4 argued that agile HR delivers in small, feedback-driven increments. This chapter examines the most widely used framework for organizing that delivery. Scrum’s intellectual roots predate the Agile Manifesto: studying unusually fast product developers such as Honda and Canon, Hirotaka Takeuchi & Ikujiro Nonaka (1986) observed that the best teams moved like a rugby pack, advancing together through overlapping phases rather than passing work down a relay of sequential specialists, and borrowed the rugby term scrum to name the pattern. Ken Schwaber and Jeff Sutherland, both signatories of the Agile Manifesto (Kent Beck et al., 2001), formalized the framework in the 1990s and continue to maintain its official definition in the Scrum Guide, which describes Scrum as a deliberately lightweight framework: three roles, three artifacts, five events, and nothing else (Ken Schwaber & Jeff Sutherland, 2020).

For HR, Scrum matters for two reasons. First, HR teams increasingly use Scrum to run their own work, redesigning an onboarding journey or building a new appraisal approach in sprints rather than as a monolithic programme (Natal Dank & Riina Hellström, 2020). Second, as organizations reorganize around agile teams, HR must understand the framework its internal customers live in daily; an HR business partner who cannot read a burndown chart or sit usefully in a retrospective cannot serve an agile business. This chapter addresses both needs: first the framework itself, then its translation into HR practice.

flowchart LR
    PB["Product Backlog<br>(prioritized needs)"] --> SP["Sprint Planning"] --> SB["Sprint Backlog"] --> S["Sprint<br>(1 to 4 weeks)"]
    S --> I["Increment<br>(usable result)"]
    S -.-> DS["Daily Scrum"]
    I --> SR["Sprint Review<br>(stakeholder feedback)"] --> RE["Retrospective<br>(process improvement)"] --> SP
    style PB fill:#e3f2fd,stroke:#1976D2
    style S fill:#fff8e1,stroke:#F9A825
    style I fill:#e8f5e9,stroke:#388E3C
    style RE fill:#ede7f6,stroke:#7E57C2

5.2 The Scrum Framework

5.2.1 Roles

Scrum defines three accountabilities. The product owner owns the what: a single person accountable for maximizing the value of the work by maintaining and ordering the product backlog. The scrum master owns the how: a servant leader accountable for the team’s effectiveness, who coaches the team in the framework, removes impediments, and protects it from interruption. The developers, in HR contexts simply the team members, own the delivery: a small, cross-functional group with every skill needed to turn a backlog item into a finished increment without hand-offs to outsiders (Ken Schwaber & Jeff Sutherland, 2020).

Common Misconception: The Scrum Master Is the Team’s Manager

The scrum master holds no authority over the team’s work assignments, appraisal, or careers, and the product owner holds authority only over the ordering of the backlog. Organizations that quietly re-badge the old team leader as scrum master and project manager as product owner reproduce the old command structure under new names, exactly the pattern Chapter 3 warned about with the Spotify model: copying labels does not copy the mechanism.

5.2.2 Artifacts

The product backlog is a single, ordered, public list of everything the product might need, expressed as items whose value a stakeholder would recognize. The sprint backlog is the subset the team has committed to for the current sprint, plus its plan for delivering it. The increment is the sum of completed work, and the framework’s most demanding rule attaches to it: every item counted as finished must meet an explicit, shared definition of done, so that “done” means genuinely usable rather than nearly complete (Ken Schwaber & Jeff Sutherland, 2020). Each artifact embodies the transparency principle of Chapter 3: the real state of work, visible to everyone.

5.2.3 Events

Scrum’s events create a fixed rhythm, or cadence, that replaces ad-hoc coordination. The sprint itself is a time-box of one month or less within which the team produces a usable increment. Sprint planning opens the sprint: the team selects backlog items and shapes a plan. The daily scrum, often called the stand-up, is a fifteen-minute synchronization in which the team inspects progress toward the sprint goal and surfaces blockers. The sprint review closes the delivery loop: stakeholders inspect the increment and the backlog is adjusted in response. The retrospective closes the learning loop: the team inspects its own process and commits to at least one improvement for the next sprint (Ken Schwaber & Jeff Sutherland, 2020).

Practitioner Insight: The Retrospective Is the Engine

Teams under deadline pressure skip the retrospective first, and it is the costliest possible saving. Every other event delivers this sprint’s work; the retrospective improves every future sprint. A team that ships imperfectly but retrospects honestly will outperform a team that ships well and never examines itself, because the first team compounds and the second does not.

5.3 Translating Scrum into HR

5.3.1 The HR Product Owner and the People Backlog

The translation begins with the product concept from Chapter 3: every HR offering, onboarding, performance support, a benefits portal, is a product with users. Each product needs an owner, a named person accountable for its value, who maintains a backlog of improvements ordered by evidence of user need rather than by seniority of requester (Natal Dank & Riina Hellström, 2020). This single change is often the most transformative: it replaces the committee-owned programme, where accountability diffuses, with visible individual ownership, and it replaces the private project plan with a public backlog that any employee can inspect.

Backlog items work best written as user stories, in the form As a [user], I want [capability] so that [benefit]. “As a new hire, I want my equipment ready on day one so that I can contribute in my first week” directs the team’s attention to an outcome for a person; “procure laptops earlier” directs it to a task. The difference in framing produces a difference in what gets tested at the sprint review: whether the person’s problem is solved, not whether the task was completed.

5.3.2 Sprints in HR Work

An HR sprint applies the time-box to people work: two weeks, a committed set of backlog items, a daily fifteen-minute stand-up, and a review at which real users, candidates, new hires, managers, react to what was built. Natal Dank & Riina Hellström (2020) emphasize that the increment must be genuinely usable: not a slide deck about a future onboarding journey, but a revised first-week schedule actually run with this fortnight’s cohort of new joiners. The definition of done for HR work should name the evidence required, for example: piloted with at least five users and feedback collected.

Worked Example: Redesigning Onboarding in Three Sprints

Sprint	Goal	Increment delivered	Review evidence
1	Understand the problem	Journey map from interviews with 12 recent hires; prioritized pain-point backlog	New hires confirm the map reflects their experience
2	Fix the sharpest pain	Day-one readiness checklist piloted with one business unit’s cohort	Time-to-productive-setup drops from 6 days to 1
3	Scale what worked	Checklist adapted and rolled out to two further units; buddy scheme prototype	Week-one satisfaction pulse rises; two units request adoption

Contrast this with the traditional alternative: a six-month onboarding project that gathers requirements for eight weeks and launches a complete programme organization-wide, discovering only at launch which assumptions were wrong.

flowchart TD
    B["People backlog:<br>onboarding pain points"] --> S1["Sprint 1:<br>Discover and map"]
    S1 --> S2["Sprint 2:<br>Pilot the fix"]
    S2 --> S3["Sprint 3:<br>Scale what worked"]
    S1 -.->|"user feedback"| B
    S2 -.->|"user feedback"| B
    S3 -.->|"user feedback"| B
    style B fill:#e3f2fd,stroke:#1976D2
    style S3 fill:#e8f5e9,stroke:#388E3C

5.3.3 Where Scrum Fits HR, and Where It Does Not

Scrum assumes work that can be batched into a sprint goal and protected from interruption for the length of the time-box. Much HR work fits: design projects, policy development, programme builds, anything exploratory with a definable goal. But a large share of HR work is flow work, arriving unpredictably and demanding immediate attention: employee-relations cases, offer approvals, queries, grievances. Forcing flow work into sprints produces either broken sprints or neglected employees. Darrell K. Rigby et al. (2020) make the general point that agile methods must be fitted to the nature of the work; for continuous-flow HR work, the Kanban method of Chapter 6 is usually the better instrument, and many HR teams run both: Scrum for their change projects, Kanban for their run-the-function work.

Common Misconception: Doing Stand-Ups Means Doing Scrum

A daily meeting grafted onto otherwise unchanged work is the most common counterfeit of Scrum in HR. Without a prioritized backlog, a genuine time-box, an empowered owner, and a review with real users, the stand-up is simply a status meeting held standing. The framework’s benefits come from the complete system of transparency, inspection, and adaptation, not from any single ceremony performed in isolation.

5.4 Case Studies

5.4.1 Case Study 1: ING’s People Function in Sprints

When ING reorganized into squads and tribes, its HR function faced a double task: supporting the transformation and transforming itself. HR adopted the same working model as the business it served, forming multidisciplinary teams that ran two-week sprints against visible backlogs, with product owners accountable for offerings such as recruitment and learning (Stephen Denning, 2018). Working in the business’s own operating rhythm changed HR’s credibility: advice about agile working now came from a function visibly practising it.

Discussion Questions:

Why does it matter whether HR uses the same operating model as the organization it advises?
Which HR offerings at a bank would you organize as Scrum products with sprints, and which as continuous-flow services?
What new skills does an HR professional need to work effectively as a member of a sprint team?

5.4.2 Case Study 2: Cisco’s HR Breakathon

In 2016 Cisco ran what it called an “HR Breakathon”: a 24-hour hackathon in which more than 800 employees across 39 countries, working in small cross-functional teams, generated over 100 prototype solutions to reimagine Cisco’s HR processes, from onboarding to internal mobility. The most promising prototypes were then developed iteratively into deployed HR products. The event compressed the essential Scrum loop, build something small, show it to users, learn, into an extreme time-box, and signalled publicly that HR solutions would be co-created with employees rather than designed for them.

Discussion Questions:

What did the hackathon format achieve that a conventional HR project could not? What can it not achieve on its own?
How does co-creating HR products with employees express the customer-centricity principle from Chapter 3?
Design a follow-up process for turning a 24-hour prototype into a production HR product using sprints.

5.5 Summary

Chapter Summary

Scrum originated in studies of fast-moving product teams (Hirotaka Takeuchi & Ikujiro Nonaka, 1986) and was formalized as a lightweight framework of three roles, three artifacts, and five events (Ken Schwaber & Jeff Sutherland, 2020). The product owner orders a transparent backlog, the scrum master serves the team’s effectiveness, and a cross-functional team delivers a usable increment each sprint, inspected by stakeholders at the review and improved through the retrospective. In HR, the framework translates into HR product owners, people backlogs written as user stories, and sprints that pilot real change with real users (Natal Dank & Riina Hellström, 2020). Scrum suits exploratory, goal-directed HR projects; continuous-flow work such as employee relations is better served by Kanban, the subject of the next chapter. ING and Cisco show the framework and its spirit applied to the HR function itself (Stephen Denning, 2018).

Key Terms

Scrum · Product owner · Scrum master · Product backlog · Sprint backlog · Increment · Definition of done · Sprint · Daily scrum · Sprint review · Retrospective · User story · HR sprint · Flow work

Summary

Concept	Description
Origins and Roles
Scrum	A lightweight framework of three roles, three artifacts, and five events for iterative delivery
Rugby-team pattern	Takeuchi and Nonaka's observation that fast product teams advance together through overlapping phases
Product owner	The single person accountable for maximizing value by ordering the product backlog
Scrum master	The servant leader accountable for team effectiveness, coaching, and impediment removal
Cross-functional team	A small team holding every skill needed to finish work without external hand-offs
Artifacts
Product backlog	The single, ordered, public list of everything the product might need
Sprint backlog	The items committed for the current sprint together with the plan to deliver them
Increment	The usable sum of completed work produced within a sprint
Definition of done	The explicit shared standard an item must meet before it counts as finished
Events
Sprint	A time-box of one month or less in which the team produces a usable increment
Sprint planning	The opening event in which the team selects items and shapes the sprint plan
Daily scrum	The fifteen-minute daily synchronization on progress and blockers
Sprint review	The stakeholder inspection of the increment that closes the delivery loop
Retrospective	The team's inspection of its own process that closes the learning loop
Scrum in HR
HR product owner	A named owner accountable for the value of an HR offering treated as a product
User story	A backlog item framed as a user, a capability, and a benefit rather than a task
HR sprint	A time-boxed cycle of HR work reviewed with real users such as new hires or managers
Flow work	Unpredictable, continuous demand such as ER cases, poorly suited to sprint batching
Case Evidence
ING People sprints	ING's HR function adopting squads, backlogs, and two-week sprints during its transformation
Cisco HR Breakathon	Cisco's 24-hour, 800-person hackathon co-creating prototype HR solutions with employees