The Agile Cheat Sheet: Every DO and DON'T From 11 Articles in One Page
Summary
- One Page, Ten Articles: Every critical lesson from the entire Agile series, distilled into DOs and DON’Ts you can pin to your monitor.
- Not Theory: These aren’t textbook rules. They’re lessons extracted from real delivery pain—each one earned the hard way.
- Team Alignment Tool: Share this with your team. If everyone agrees on these, half your process problems disappear.
You’ve read ten articles. You’ve seen the ceremonies, the frameworks, the real-world examples. But when you’re in the middle of a sprint and things are getting messy, you don’t have time to re-read a 2000-word article. You need a quick reference. This is that reference. Every DO and DON’T below is extracted directly from the series—with a link back to the full article if you need the context. Pin it. Print it. Make it your team’s constitution.
What’s Inside
| # | Phase | Key Idea |
|---|---|---|
| 1 | Agile Mindset | Principles over rules |
| 2 | Backlog Refinement | Kill weak ideas early |
| 3 | Grooming | Sell the vision |
| 4 | Technical Analysis | No grey areas in the sprint |
| 5 | Sprint Planning | Commitment, not brainstorming |
| 6 | Daily Standup | Are we on track? |
| 7 | Retrospective | Actions, not wishes |
| 8 | Sprint Review | Customer as co-creator |
| 9 | INVEST Criteria | Break it down or it breaks you |
| 10 | DoR & DoD | Shippable tonight |
Agile Mindset (Series #1)
The foundation. Before you touch any ceremony, internalize this: Agile gives you principles, not procedures. Your team adapts them to your context. The moment you start asking “does Scrum say this?” instead of “does this help us deliver?”, you’ve lost the plot.
DO
Treat Agile as a constitution—it gives principles, your team interprets them. Use trade-offs when reality hits mid-sprint. Accept that adopting Agile will increase chaos temporarily because it stops hiding problems.
DON'T
Ask “does Scrum say this?” for every problem. Follow frameworks blindly without understanding the “why.” Expect everything to get better overnight—Agile makes problems visible, it doesn’t magically solve them.
→ Full article: Agile Overview
Backlog Refinement (Series #2)
Where ideas go to die — or survive. The Product and Business teams filter the backlog before engineers ever see it. If an idea can’t pass napkin math for ROI, it doesn’t deserve a ticket.
DO
Kill weak ideas early with back-of-the-envelope math. Compare all work types (Legal, Revenue, Cost-Down) using EBITDA impact. Choose smaller effort when ROI is similar—Time to Market wins.
DON'T
Drag engineers into Refinement meetings—filtering is the Product/Business team’s job. Waste time analyzing ideas that fail the napkin math. Let “junk” ideas survive into the development phase.
→ Full article: Backlog Refinement
Grooming (Series #3)
The bridge between “what” and “how.” The PO presents upcoming work, the team asks clarifying questions, and unclear items get sent back. No technical solutioning here — just making sure everyone understands the problem.
DO
Sell the vision—the PO should make the team want to build this. Show work 2-3 sprints ahead to give context and ignite passion. Send unclear items back to the PO if functional questions can’t be answered.
DON'T
Read tickets like a robot—that kills engagement. Accept ambiguity in requirements. Discuss how to code it—that’s for Technical Analysis.
Technical Analysis (Series #4)
The session where engineers own the conversation. QA writes test cases first (defining the target), the team decomposes work into technical tasks, and risks get surfaced while they’re still drawings on a whiteboard.
DO
Have QA write test cases before coding starts—they define the target. Decompose work into technical tasks with clear DB changes, API contracts, and refactoring needs. Run a pre-mortem to surface risks while they’re still drawings on a whiteboard.
DON'T
Enter the sprint with grey areas or unknowns. Skip POC/Spike when there’s genuine uncertainty. Say “we’ll figure it out as we code”—that’s not Agile, that’s gambling.
→ Full article: Technical Analysis
Sprint Planning (Series #5)
The commitment ceremony. The team pulls work they believe they can deliver, explains their plan back to the PO, and locks in. No new requirements, no brainstorming — just “this is what we’ll ship this sprint.”
DO
Let the team lead the conversation—PO listens and validates. Use a pull-based flow: members pull the next highest-priority item when ready. Deliver the first testable item to QA by end of Day 1. Invest 20-40% of sprint effort in Pair Programming to break silos.
DON'T
Discover new requirements in Planning—if that happens, you’ve already failed. Assign all tickets upfront—it creates silos and kills flexibility. Let Planning become a brainstorming session—commitment only.
→ Full article: Sprint Planning
Daily Standup (Series #6)
The 15-minute (max) pulse check. Walk the board right-to-left, surface blockers, align on today’s plan. If it regularly takes longer than 7 minutes in a mature team, something is broken.
DO
Walk the board right-to-left—start with items closest to Done. Focus on the Sprint Goal: “Are we on track or are we screwed?” Scream immediately when blocked—don’t wait for the next Daily. Use Parking Lot for anything requiring more than 3 sentences.
DON'T
Give status reports or recite Jira ticket numbers. Let it exceed 15 minutes—a mature team finishes in 6-7 minutes. Report “up” to management—the Daily is for the team. Let someone stay stuck on the same item for 3 days without anyone asking “do you need help?”
Retrospective (Series #7)
The only ceremony that improves the process itself. Every action item needs a definition, an owner, and a deadline. Anything less is a wish — and wishes don’t ship.
DO
Define every action with three components: Definition + Owner + Deadline. Give substantive, data-driven praise—explain what went well and why it matters. Stay focused on that sprint and your circle of influence.
DON'T
End with wishes like “we should test better”—that’s not an action, that’s noise. Give hollow praise (“Great sprint, team!”) or destructive criticism. Discuss office cafeteria, HR policies, or anything outside your circle of influence. Skip follow-through—untracked actions erode trust.
Sprint Review (Series #8)
Where working software meets stakeholder feedback. Show real functionality (not polished slides), ask hard questions, and update the backlog based on what you learn. The customer becomes a co-creator, not a critic at delivery.
DO
Get the customer into the process—make them co-creators, not critics at delivery. Show working software, warts and all. Ask hard questions to surface real feedback: “What would you change?” Update the backlog based on what you learn.
DON'T
Turn it into a polished demo show with rehearsed slides. Skip Review when the sprint is incomplete—show progress, get early feedback. Ignore silence—if stakeholders aren’t giving feedback, they’re disengaged. Gather feedback but never change the backlog.
INVEST Criteria (Series #9)
The quality test for every user story. Each story must be Independent, Negotiable, Valuable, Estimable, Small, and Testable. If it’s bigger than 13 SP, it hasn’t been broken down enough — use the INVEST checklist to verify.
DO
Break every story into Independent, Small, Testable pieces. Remember: even populating a single combobox is a standalone, testable story. Use Feature Toggles—deploy to production without opening to users. Accept that 3 small deployments beat 1 big-bang release.
DON'T
Write monster stories with 13+ Story Points—there’s no task that big, only tasks that haven’t been broken down. Try to deliver all features at once. Confuse “deploying” with “releasing”—they are fundamentally different things.
→ Full article: INVEST Criteria
DoR & DoD (Series #10)
The team’s contract with itself. Definition of Ready gates what enters the sprint; Definition of Done gates what leaves it. “I wrote the code” is never enough — “Done” means the team can ship it tonight and sleep well.
DO
Treat DoD as a team charter—if the increment can’t be delivered, the whole team owns it. Use DoR as a standard: if it doesn’t meet the bar, it doesn’t enter the sprint. Evolve both definitions in Retros based on what you learn.
DON'T
Accept “I wrote the code, I’m done”—that’s an individual mindset, not a team mindset. Skip definitions under deadline pressure—the moment you bend them, they’re meaningless. Let checklists grow beyond 5-7 items—checkbox theater helps no one.
The One-Page Cheat Sheet
If you only take one thing from each article, make it these:
| # | Phase | The One Rule |
|---|---|---|
| 1 | Overview | Agile is a constitution, not a law book. Interpret it. |
| 2 | Refinement | If the napkin math doesn’t work, kill the idea. |
| 3 | Grooming | Sell the vision. If the team doesn’t care, they won’t build it well. |
| 4 | Technical Analysis | No grey areas enter the sprint. QA defines the target first. |
| 5 | Sprint Planning | Planning is commitment, not brainstorming. |
| 6 | Daily Standup | Are we on track? That’s the only question. |
| 7 | Retrospective | Actions, not wishes. Owner + Deadline or it didn’t happen. |
| 8 | Sprint Review | Get the customer in the game, or they’ll be against you at delivery. |
| 9 | INVEST | No big tasks exist. Only tasks not broken down enough. |
| 10 | DoR & DoD | ”Done” means the team can ship it tonight and sleep well. |
The Bottom Line
This guide isn’t meant to replace the detailed articles—it’s meant to keep you honest between readings. The difference between teams that deliver and teams that struggle usually isn’t knowledge. It’s discipline. They know the same things you know. They just do them consistently. Pin this list somewhere visible. Review it in your next Retro. And when someone on your team says “I wrote the code, I’m done,” point them to this page.