Simpro Knowledge Base

Agile Scrum Kanban Cheatsheet

Agile Scrum Kanban Cheatsheet visual map

Purpose

This page gives practical guidance for using Agile, Scrum, and Kanban at Simpro without turning process into ceremony theater.

The goal is:

Minimum process, maximum value.

Agile In One Minute

Agile is a way to learn and adapt while delivering working software.

It values:

  • People and collaboration.
  • Working software.
  • Customer collaboration.
  • Responding to change.

Agile is not equal to standups, story points, or two-week sprints. Those may help, but only if they improve flow, feedback, quality, and learning.

Scrum Quick Reference

Use Scrum when work benefits from a planning/review cadence.

Events:

  • Sprint planning: choose goal and work.
  • Daily Scrum: inspect progress and adapt.
  • Sprint review: show working software and learn.
  • Retrospective: improve how the team works.

Artifacts:

  • Product backlog.
  • Sprint backlog.
  • Increment.

Values:

  • Commitment.
  • Focus.
  • Openness.
  • Respect.
  • Courage.

Kanban Quick Reference

Use Kanban when work arrives continuously or flow matters more than sprint boundaries.

Core practices:

  • Visualize work.
  • Limit work in progress.
  • Manage flow.
  • Make policies explicit.
  • Improve collaboratively.

Useful metrics:

  • Cycle time.
  • Work item age.
  • Throughput.
  • Blocked time.
  • WIP.

Scrum Vs Kanban

Context Better Fit
Product feature team with cadence Scrum or hybrid
Support/operations-heavy team Kanban
Platform team handling requests and roadmap Kanban plus quarterly goals
Discovery-heavy uncertain work Dual-track discovery with experiments
Incident-heavy work Kanban with SLO/toil review

Story Writing

Use this when helpful:

As a <user>
I want <capability>
So that <outcome>

But do not force every item into this format. Some work is technical, operational, or exploratory.

Better story thinking includes:

  • User.
  • Problem.
  • Outcome.
  • Acceptance examples.
  • Risks.
  • Metrics.

Acceptance Criteria

Good acceptance criteria are specific and testable.

Weak:

Dashboard should work.

Better:

Given a manager has active jobs, when they open the dashboard, then they can see the top three staffing risks for the current week within five seconds.

Definition Of Ready

Work is ready when:

  • Problem and outcome are clear.
  • Dependencies are known.
  • Acceptance examples exist.
  • Risks are visible.
  • Design/API questions are resolved enough to start.
  • The item is small enough to complete.

Definition Of Done

Work is done when:

  • It solves or validates the intended problem.
  • Code is reviewed.
  • Tests appropriate to risk are complete.
  • Important logs/metrics exist.
  • Security/privacy concerns are addressed.
  • Performance impact is acceptable.
  • Documentation/runbook is updated if needed.
  • It is released or has a clear release path.

Daily Standup

Avoid status theater.

Better questions:

  • What changed since yesterday?
  • What is blocked?
  • What risk became visible?
  • What decision is needed?
  • Are we still on track for the sprint/flow goal?

Retrospective

Retros should produce system improvement.

Useful format:

  • What helped flow?
  • What hurt flow?
  • What quality risk appeared?
  • What did we learn?
  • What one improvement will we try next?

Anti-Patterns

  • Story points used as productivity weapon.
  • Standups that become manager reporting.
  • Sprint reviews with no working software.
  • Retrospectives with repeated complaints and no action.
  • Backlogs full of solutions but no problems.
  • Kanban boards with unlimited WIP.
  • "Agile" used to mean unclear commitment.

Simpro Guideline

Use Scrum/Kanban to improve:

  • Clarity.
  • Flow.
  • Feedback.
  • Quality.
  • Learning.

If a ritual does not improve one of these, change it.

Team Reference Guide

How To Explain This Page

Use this page as a reference conversation, not as a checklist to read aloud. Start by explaining why the topic matters, then connect it to current team work, and finally ask what behavior should change.

The most useful way to teach this material is to move from concept to example. Explain the principle, show how it appears in daily work, ask the team where it is currently strong or weak, and finish with one small action.

Guidelines For Teams

  • Connect the topic to a current project, customer problem, incident, or decision.
  • Translate concepts into visible behaviors.
  • Keep the guidance lightweight enough to use weekly.
  • Capture decisions, examples, and improvements back into the wiki.
  • Review the page again after a project, incident, or retrospective to update what the team has learned.

Reflection Questions

  • What part of this topic is already working well for us?
  • What part is still mostly theory?
  • What is one behavior we can change in the next 30 days?