How to Actually Live the 5 Scrum Values

“We value the 5 Scrum values.” No, you probably don’t.

Most teams say they live the Scrum values. Then:

Nobody speaks up when estimates are obviously wrong.
Stakeholders demand “just one more feature” every sprint.
Retrospectives are awkward, quiet, and pointless.
The same blockers appear sprint after sprint.

In a 2022 State of Agile report, only ~30% of organizations said they were “very satisfied” with their agile practices—despite most claiming to “do Scrum.” The gap isn’t process. It’s values.

Let’s stop pretending the 5 Scrum values are posters on the wall and treat them like constraints on how we actually behave:

Commitment
Focus
Openness
Respect
Courage

I’ll walk through each value, how teams fake it, and what it looks like when you actually live it—down to specific behaviors, conversations, and changes you can make this week.

1. Commitment: Not “We’ll try” — “We own this”

Most teams treat commitment like a vague promise: “We’ll do our best.” That’s not commitment; that’s hedging.

In Scrum, commitment isn’t “we commit to this scope no matter what.” It’s:

We commit to a clear goal, and we own the outcome and the learning.

How teams fake commitment

Common smells:

Sprint Planning ends with: “Let’s pull a few more tickets, just in case.”
People say “I’ll try to get to it” instead of “I’ll do X by Y.”
Product Owners change the goal mid-sprint: “Can we just squeeze in this one urgent thing?”
The sprint backlog is treated as a suggestion, not a real plan.

In one team I coached, only 40–50% of sprint backlog items were finished on average. The team was “busy,” but never reliable. Stakeholders stopped trusting any dates.

What real commitment looks like

Tangible behaviors:

The sprint has one clear Sprint Goal, not a laundry list.
The team says “no” to work that doesn’t support the goal.
Every backlog item has a clear Definition of Done the team agrees to.
People speak in specifics:
- “I’ll finish API integration by Wednesday noon and demo it in the afternoon.”
- “I can’t commit to that timeline with the current scope. Here’s what I can commit to.”

How to strengthen commitment (this week)

Add a hard rule to Sprint Planning:
“If it doesn’t support the Sprint Goal, it doesn’t go in the sprint.”
Track commitment reliability:
- % of sprint backlog completed
- % of sprint goals met
  Discuss these in retrospectives. If you’re consistently below ~80%, you’re overcommitting or allowing scope creep.
Ban “I’ll try” from your vocabulary:
Ask: “What will you do, and by when?” If someone can’t answer, the work isn’t understood enough to commit to it.

2. Focus: Stop being “busy,” start being brutal

Most Scrum teams are overloaded. That’s not a bug; it’s a choice.

Context switching kills productivity. Research from the University of California, Irvine shows it can take 23 minutes to refocus after a context switch. Multiply that by Slack pings, drive‑by requests, and multiple projects, and your “8-hour day” has maybe 3 hours of real focus.

How teams fake focus

Everyone is in too many meetings; deep work is an exception.
Developers are on 2–3 projects simultaneously “to keep them fully utilized.”
The board is full of “In Progress” tickets that stay there for days.
Sprint Goals are so vague they’re meaningless: “Improve platform stability.”

What real focus looks like

The team works on fewer things at a time and finishes them faster.
WIP (Work In Progress) is limited, and people respect those limits.
Interruptions are treated as exceptions, not the norm.
The Sprint Goal is specific enough that you can say, “Does this task help us hit the goal or not?”

Example of a focused Sprint Goal:

“Enable users to reset their password via email and measure reset success rate.”

How to increase focus (without starting a revolution)

Introduce WIP limits today:
- Start with:
  - “In Progress” column: max 2 items per developer
  - “Code Review” column: max 2 per reviewer
- When you hit the limit, no one starts new work. They help finish existing work.
Block focus time on calendars:
- 2–3 afternoons per week with no internal meetings.
- Leaders must respect this or it dies instantly.
Make your Sprint Goal a filter:
- In Daily Scrum, ask: “What did I do yesterday that moved us toward the goal? What will I do today that moves us toward the goal?”
- If you can’t answer, you’re not focused.

3. Openness: If nobody is uncomfortable, you’re not being honest

Teams love “transparency” until it includes bad news.

Openness isn’t just sharing a dashboard. It’s being honest about risk, uncertainty, and problems—even when it makes you look bad.

How teams fake openness

Status updates are always “yellow,” never red.
Risks are mentioned but not quantified: “Performance might be an issue.”
Estimates are padded privately instead of discussing uncertainty openly.
People know a date is impossible but say nothing until the last week.

In one organization, roadmap dates were set top‑down. Teams knew they were unrealistic but stayed quiet. Result: missed deadlines, weekend work, and a toxic culture of blame.

What real openness looks like

The team shares bad news early, with options.
Estimates include ranges and assumptions:
- “If we don’t hit unknowns, 3–5 days. If we hit X or Y risk, up to 8.”
Retrospectives surface real issues:
- “Our PO interrupts us mid-sprint with new priorities. We can’t work like this.”
Stakeholders see real progress, not polished slide decks.

How to practice openness without chaos

Make risk a first-class citizen in refinement:
- For each item, ask:
  - What don’t we know yet?
  - What could make this twice as long?
  - How will we know early if we’re in trouble?
Use visual risk signals on your board:
- Add tags or labels: “High uncertainty,” “External dependency,” “New tech.”
Change how you escalate bad news:
- Don’t just say, “We’re behind.”
- Say, “We’re behind because X. Here are 2–3 options and their trade-offs.”

Openness without options is complaining. Openness with options is leadership.

4. Respect: Stop being “nice” and start being useful

A lot of teams confuse respect with politeness. They avoid hard feedback to “keep the peace” and call it respect. It’s not.

Respect in Scrum means:

I believe you’re a capable professional, so I’ll give you clear information, honest feedback, and space to do your job.

How teams fake respect

Decisions are made in private, then “communicated” to the team.
Product Owners treat developers like ticket machines.
Developers ignore UX or QA input.
Underperformers are quietly carried by the rest of the team for months.

The result: resentment, disengagement, and slow erosion of trust.

What real respect looks like

People are trusted with problems, not just tasks:
- “We need to reduce onboarding drop‑off by 20%, what are your ideas?”
Feedback is direct and timely:
- “When you merge without reviews, it slows us down later. We need you to follow the process.”
The team protects each other’s time:
- No surprise 4 p.m. meetings.
- No “quick favors” that blow up someone’s day.
Leadership respects empirical data over hierarchy:
- If the team’s velocity, defect rate, and lead time say we can’t hit a date, that data matters.

How to build respect into your rituals

Change how you do Sprint Reviews:
- Let developers demo their own work.
- Let testers talk about quality trends.
- Let designers walk through key decisions.
Use clear working agreements:
- Examples:
  - “No meetings during 1–4 p.m. unless it’s production down.”
  - “Code review turnaround within 24 hours.”
  - “If you’re blocked >1 day, you must escalate.”
- Revisit these monthly. Enforce them consistently.
Address performance issues early:
- Pair programming, mentoring, and explicit expectations beat months of silent frustration.

5. Courage: The value everyone prints and nobody funds

Courage is the most violated Scrum value—and the one that actually changes culture.

Courage means:

Saying “no” when it’s easier to say “yes.”
Admitting “we don’t know” in front of important people.
Challenging harmful behavior, even from senior leaders.

How teams fake courage

They complain privately but stay silent in planning, reviews, and retros.
Scrum Masters facilitate ceremonies but never challenge scope or behavior.
Product Owners accept unrealistic dates, then pressure the team.
Everyone blames “the business” instead of confronting specific decisions.

What real courage looks like

Scrum Masters saying:
- “We can’t commit to that scope and that date. Which is more important?”
Product Owners saying:
- “We’re stopping this feature. The data doesn’t justify the investment.”
Developers saying:
- “We can hack this in 2 days, or do it properly in 5. Here are the risks.”
Teams saying:
- “We will not ship without this minimal level of automated tests. The risk is too high.”

How to grow courage without getting fired

This is where people get stuck: “I’d like to push back, but I like my job.”

Tactical ways to be courageous and professional:

Use data instead of emotion:
- “Our average lead time is 8 days. To deliver this in 3, we’d need to drop X and Y.”
Offer trade‑offs, not ultimatums:
- “We can either keep the date and cut scope, or keep the scope and move the date. Which do you prefer?”
Start small:
- Challenge one unrealistic request per sprint.
- Raise one uncomfortable topic per retrospective.
Scrum Masters: stop being meeting organizers:
- Your job is to protect empiricism and the team’s ability to deliver.
- If nobody is ever mildly annoyed with you, you’re probably not doing the hard parts of the role.

Common Mistakes: How teams quietly kill the Scrum values

Here’s how well‑intentioned teams undermine the values without noticing:

Using Scrum terms, ignoring Scrum principles
- Daily Scrums as status reports to the manager.
- Sprint Reviews as slide presentations, not working software.
Rewarding heroics over healthy systems
- Celebrating all‑nighters instead of asking why they were needed.
- Promoting people who say “yes” to everything.
Over‑reliance on tools
- Treating Jira as the process instead of a reflection of it.
- Measuring story points like output instead of using them to learn.
Skipping or trivializing retros
- 30-minute retro with no actions = ritual, not improvement.
- Same issues every sprint = no follow‑through.

If any of these sound familiar, you don’t need a new framework. You need to realign behavior with the values you already claim to hold.

Making the Scrum Values Real: Concrete Moves You Can Make This Month

Here’s a focused, tactical playbook to bring the 5 values to life.

1. Redesign your Sprint Planning around Commitment & Focus

Next Sprint Planning, do this:

Start with the Sprint Goal, not the backlog.
- Write it in one sentence.
- If you can’t, you’re not ready to plan.
Estimate as a team and discuss uncertainty explicitly.
- Call out risks and unknowns.
Limit work to what you can realistically finish.
- Use your last 3–5 sprints of data as a guide.
End with a clear verbal commitment:
- “We commit to achieving this Sprint Goal, given what we know today.”

2. Upgrade your Daily Scrum to support Focus & Openness

Stop going around the circle with “yesterday/today/blockers” autopilot.

Try this format:

“What did I do yesterday that moved us toward the Sprint Goal?”
“What will I do today that moves us toward the Sprint Goal?”
“What’s at risk of not getting done, and what do I need from the team?”

Keep it under 15 minutes. Take problem‑solving offline. Make risk visible.

3. Make your Retrospectives about Courage & Respect

Next retro, ask sharper questions:

“What are we not talking about that we should be?”
“What behavior did we tolerate this sprint that hurt the team?”
“If we had 50% less time, what would we stop doing immediately?”

Then:

Pick 1–2 concrete experiments for the next sprint.
Assign owners and due dates.
Review last retro’s actions first in the next retro. No follow‑through = no trust.

4. Align leadership behavior with the values

If you’re a manager, PO, or senior leader:

Stop asking, “Can you just squeeze this in?”
Instead ask: “What would we need to drop to include this?”
Reward people who surface problems early.
Don’t punish the messenger.
Ask teams for options, not obedience.
“What are 2–3 ways we could approach this, and what are the trade-offs?”

When leadership behavior contradicts the values, the values lose. Every time.

Tools can help—but they won’t do the hard parts for you

No tool will make your team courageous or focused. But good tools can reduce friction so you can spend your energy on the real work: conversations and decisions.

For example, using something like ScrumPoi for planning poker and retrospectives can reduce anchoring bias with anonymous voting, integrate estimates directly into Jira, and let you spin up sessions without signup overhead. That makes it easier to have honest discussions about effort, risk, and improvement—if you’re willing to have them.

Living the values is the work

If your team is:

Constantly “almost done”
Afraid to say “no”
Quiet in retros
Busy but unreliable

You don’t have a process problem. You have a values problem.

The 5 Scrum values are not motivational posters. They are constraints on how you plan, decide, and behave. When you treat them that way:

Commitment makes your plans credible.
Focus makes your effort count.
Openness makes your risks manageable.
Respect makes your collaboration real.
Courage makes improvement possible.

Pick one value. Make one visible change this sprint. Then another next sprint.

Don’t declare you “live the Scrum values.” Prove it in how you work.

How to Actually Live the 5 Scrum Values (Not Just Talk About Them)