Scrum
Random

Click random to get a fresh chapter.

Agile-and-Scrum: Scrum Values, 2020 Guide - Hyper-Practical Study Guide

Scrum Values (2020 Guide) – Hyper-Practical Study Guide

For engineers, product owners, and Scrum Masters who need to live these values—not just memorize them.

---

1. What This Is & Why It Matters

Scrum Values (Commitment, Courage, Focus, Openness, Respect) are the operating system of your Scrum Team. They’re not fluffy HR slogans—they’re hard constraints that determine whether your team ships working software or spirals into chaos.

Why this matters in production: - Without Commitment: Your Sprint Goal becomes a "best effort" wishlist. Deadlines slip, stakeholders lose trust, and engineers burn out from last-minute heroics. - Without Courage: No one dares to kill a failing feature, refactor legacy code, or push back on unrealistic demands. Technical debt snowballs. - Without Focus: Your team multitasks across 10 "urgent" requests, delivering nothing of value. Cycle time explodes. - Without Openness: Bugs get hidden, dependencies go uncommunicated, and the team operates in silos. Outages happen in production. - Without Respect: Engineers dismiss product ideas, PMs ignore technical risks, and retrospectives turn into blame sessions. Talent quits.

Real-world scenario: You inherit a team where: - The Product Owner (PO) commits to 20 story points every Sprint, but the team consistently delivers 12. - Engineers avoid pairing on complex tasks because "it’s faster to do it alone." - The last retrospective was a 10-minute formality where no action items were created. - A critical bug was discovered in production after the Sprint Review because no one wanted to "rock the boat" by delaying the demo.

This guide will show you how to diagnose and fix these problems using Scrum Values as your toolkit.

---

2. Core Concepts & Components

? Commitment

Definition: The team collectively pledges to achieve the Sprint Goal and deliver the forecasted work. Production insight: - If your team’s velocity is 15 points but the PO demands 25, commitment is already broken. The Sprint Goal becomes meaningless. - Fix: Use historical data (e.g., last 3 Sprints’ velocity) to set realistic forecasts. If stakeholders push back, say: "We’ll commit to what we can deliver, not what you hope for."

? Courage

Definition: The willingness to do the right thing, even when it’s hard—speaking up about risks, killing bad ideas, or admitting mistakes. Production insight: - Without courage: - Engineers don’t flag technical debt because "the PO won’t prioritize it." - The team ships a half-baked feature to "meet the deadline," causing a production outage. - With courage: - You say: "This API change will break 3 downstream services. We need to refactor first." - You cancel a Sprint if the goal is no longer viable (e.g., a key dependency is delayed).

? Focus

Definition: The team works on one thing at a time, minimizing context-switching and distractions. Production insight: - Multitasking kills productivity. Studies show it takes 23 minutes to regain focus after an interruption. - Fix: - Limit Work in Progress (WIP) in your Sprint Backlog (e.g., max 2-3 stories per developer). - Use Swarming (the whole team works on one story until it’s done) for critical items.

? Openness

Definition: Transparency about progress, risks, and challenges—no hidden work, no "surprise" blockers. Production insight: - Without openness: - A developer silently struggles with a task for 3 days, then announces it’s "80% done" (it’s actually 20%). - The team discovers a major dependency after the Sprint starts. - With openness: - Daily Scrum: "I’m blocked on the database migration—can someone pair with me?" - Sprint Planning: "This story depends on Team X’s API, which isn’t ready yet."

? Respect

Definition: Valuing each team member’s expertise, time, and contributions—no dismissing ideas, no interrupting, no "that’s not my job." Production insight: - Without respect: - Engineers ignore the PO’s business context: "Why do we need this? It’s stupid." - The PO overrides technical decisions: "Just ship it—we’ll fix it later." - With respect: - The PO says: "I trust your expertise—what’s the best way to implement this?" - Engineers say: "I understand the business need—here’s how we can do it safely."

---

3. Step-by-Step: How to Live Scrum Values in a Sprint

Prerequisites: - A Scrum Team (PO, SM, Developers). - A Sprint Backlog with a clear Sprint Goal. - A Definition of Done (DoD).

Step 1: Set a Realistic Commitment (Sprint Planning)

Task: Forecast the Sprint Backlog based on historical velocity. How to do it:
1. Look at the last 3 Sprints’ velocity (e.g., 12, 14, 13 points).
2. Calculate the average: (12 + 14 + 13) / 3 = 13 points.
3. The PO proposes 20 points. Push back: plaintext PO: "We need to deliver 20 points this Sprint." You: "Our average velocity is 13. If we commit to 20, we’ll either: - Miss the Sprint Goal (hurting trust), or - Cut corners (hurting quality). Let’s pick the top 13 points that align with the Sprint Goal."
4. Outcome: The team commits to 13 points with a clear Sprint Goal.

Step 2: Create a "Courage Board" (Sprint Planning)

Task: Identify risks that require courage to address. How to do it:
1. Add a column to your Sprint Backlog (physical or digital) called "Courage Items."
2. Ask the team: "What’s one thing we’re afraid to say but need to address?" - Example entries: - "The legacy auth system might fail under load—we need to refactor." - "The PO keeps adding last-minute stories—we need to enforce the Sprint Goal."
3. Assign an owner to each item (e.g., "Alice will raise the auth risk in the next refinement.").
4. Outcome: Risks are visible and actionable.

Step 3: Enforce Focus with WIP Limits (Daily Scrum)

Task: Prevent multitasking by limiting Work in Progress. How to do it:
1. Set a WIP limit (e.g., max 2 stories per developer).
2. During the Daily Scrum, ask: plaintext "What’s your WIP right now? Are you blocked on anything?"
3. If someone has 3+ stories in progress: - Swarm on the highest-priority item. - Example: plaintext Dev A: "I’m working on Story 1, but I’m blocked on the API." Dev B: "I’ll pair with you to unblock it—let’s finish Story 1 before starting Story 2."
4. Outcome: Cycle time drops, and stories get "Done" faster.

Step 4: Run an "Openness Check" (Mid-Sprint)

Task: Surface hidden blockers before they derail the Sprint. How to do it:
1. Mid-Sprint (e.g., Day 5), ask the team: plaintext "What’s one thing you’re not saying that might impact the Sprint Goal?"
2. Use anonymous voting (e.g., Mentimeter, sticky notes) if the team is hesitant.
3. Example responses: - "I’m stuck on the payment integration—no one’s available to help." - "The QA environment is down, but I didn’t want to interrupt the PO."
4. Action items: - Pair on the payment integration. - Escalate the QA environment issue to the SM.
5. Outcome: Blockers are resolved before they become emergencies.

Step 5: Reinforce Respect with a "Feedback Sandwich" (Retrospective)

Task: Give constructive feedback without demotivating the team. How to do it:
1. Structure feedback as: plaintext 1. What went well (respect). 2. What could improve (openness). 3. How we’ll fix it (commitment).
2. Example: plaintext "I appreciate that we shipped the login feature on time (what went well). However, the last-minute changes caused a bug in production (what could improve). Next Sprint, let’s add a ‘code freeze’ 24 hours before the review (how we’ll fix it)."
3. Outcome: Feedback is actionable, not personal.

---

4.-Production-Ready Best Practices

Commitment

• Use historical velocity (not gut feelings) to set forecasts.
• Say "no" to scope creep—protect the Sprint Goal like a firewall.
• Track commitment metrics:
• % of Sprints where the team met the Sprint Goal.
• % of stories completed vs. forecasted.

Courage

• Create a "Courage Budget"—allocate 10% of Sprint capacity for technical debt or risk mitigation.
• Kill bad ideas early. Example: plaintext PO: "Let’s add a chatbot to the checkout page!" You: "That’s a 3-month project. Our Sprint Goal is ‘reduce cart abandonment.’ Let’s A/B test a simpler fix first."
• Celebrate "courageous acts" in retrospectives (e.g., "Thanks for speaking up about the security risk!").

Focus

• Ban "urgent" interruptions during the Sprint (e.g., "All requests go through the PO").
• Use timeboxing for meetings (e.g., Daily Scrum = 15 mins max).
• Visualize WIP with a Kanban board (e.g., Trello, Jira).

Openness

• Make blockers visible (e.g., a "Blocked" column on the board).
• Run "pre-mortems" before the Sprint: plaintext "It’s the end of the Sprint, and we failed. What went wrong?"
• Share bad news early. Example: plaintext "The database migration is riskier than we thought. We might need an extra day."

Respect

• Assume positive intent. Example: plaintext PO: "Why is this taking so long?" You: "Let me explain the technical challenges—here’s how we can adjust the scope."
• Rotate roles (e.g., let a developer facilitate the retrospective).
• Avoid "us vs. them" language (e.g., "The PO is unreasonable"-"How can we align on priorities?").

---

5. Common Mistakes & Traps

Mistake	Symptom	Fix/Prevention
Overcommitting	Team misses Sprint Goal 3 Sprints in a row.	Use historical velocity to set forecasts.
Avoiding hard conversations	Technical debt grows, bugs slip into production.	Create a "Courage Board" to surface risks.
Multitasking	Stories take 2x longer to complete.	Enforce WIP limits (e.g., max 2 stories per dev).
Hiding blockers	A task sits in "In Progress" for 5 days with no updates.	Run an "Openness Check" mid-Sprint.
Dismissing ideas	Engineers stop suggesting improvements.	Use "Feedback Sandwich" in retrospectives.

---

6.-Exam/Certification Focus

Typical Question Patterns

1. "Which Scrum Value is violated when…?"
2. Example: "The team doesn’t tell the PO about a major risk until the Sprint Review." Answer: Openness.

3. Trap: "Commitment" is tempting, but the issue is hiding the risk, not failing to deliver.

4. "What’s the best way to handle…?" (Scenario-based)

5. Example: "The PO keeps adding stories mid-Sprint. What should the team do?" Answer: "Remind the PO that the Sprint Goal is fixed and new work should go into the Product Backlog." Trap: "Push back and refuse to do the work" (too aggressive).

6. "Which Scrum Value encourages…?"

7. Example: "Which value encourages the team to speak up about technical debt?" Answer: Courage. Trap: "Openness" is close, but speaking up requires courage.

Key Distinctions

• Commitment vs. Forecasting:
• Commitment = The team’s pledge to achieve the Sprint Goal.
• Forecast = The work the team thinks they can complete (based on velocity).

• Exam trap: "The team commits to 20 points" (wrong—commitment is to the Goal, not the points).

• Openness vs. Transparency:

• Openness = Willingness to share challenges.
• Transparency = Making information visible (e.g., burndown charts).
• Exam trap: "The team is transparent but not open" (e.g., they show progress but hide blockers).

---

7.-Hands-On Challenge

Challenge: Your team’s velocity is 15 points, but the PO insists on 25 points for the next Sprint. The Sprint Goal is "Improve checkout conversion by 10%." Task: Write a script (in plain English) for how you’d handle this in Sprint Planning.

Solution:

1. Acknowledge the business need:
   "I understand the pressure to deliver more. Let’s focus on the Sprint Goal first."

2. Show data:
   "Our average velocity is 15 points. If we commit to 25, we’ll likely miss the Goal."

3. Propose a compromise:
   "Let’s pick the top 15 points that directly impact checkout conversion.
   If we finish early, we can pull in more work."

4. Escalate if needed:
   "If 15 points isn’t enough, let’s discuss trade-offs—what can we deprioritize?"

Why it works: - Uses Commitment (realistic forecast) and Courage (pushing back). - Aligns with the Sprint Goal, not just story points.

---

8.-Rapid-Reference Crib Sheet

Value	Key Action	Anti-Pattern
Commitment	Forecast based on velocity.	Committing to more than historical velocity.
Courage	Kill bad ideas early.	Avoiding hard conversations.
Focus	Limit WIP (max 2 stories per dev).	Multitasking across 5+ stories.
Openness	Surface blockers in Daily Scrum.	Hiding risks until the Sprint Review.
Respect	Assume positive intent.	Dismissing others’ ideas.

Exam Traps: - "The team commits to story points"-Wrong (commitment is to the Sprint Goal). - "Openness means sharing all details"-Wrong (it’s about relevant challenges, not oversharing). - "Courage means taking on more work"-Wrong (it’s about doing the right thing, not the easy thing).

---

9.-Where to Go Next

1. Scrum Guide 2020 (Official): https://scrumguides.org/
2. Book: "Scrum: The Art of Doing Twice the Work in Half the Time" (Jeff Sutherland)
3. Video: "Scrum Values in Action" (Scrum.org YouTube)
4. Tool: Use Miro or Mural to visualize WIP and blockers in real time.

---

Final Thought: Scrum Values aren’t abstract—they’re debugging tools for your team. When something feels "off," ask: - Are we overcommitting? (Commitment) - Are we avoiding hard truths? (Courage) - Are we multitasking? (Focus) - Are we hiding blockers? (Openness) - Are we dismissing each other? (Respect)

Fix the value, and the process will follow.