ENGIMY.IO - CHEATSHEET
AGILE × QUICK REFERENCE
AGILE
SOFTWARE ENGINEERING REFERENCE

AGILE &
SCRUM CHEATSHEET.

A comprehensive reference for Agile and Scrum – principles, roles, ceremonies, artefacts, and best practices. All in one place.

REFERENCE v1.0

Agile & Scrum Quick Reference

Everything you need day‑to‑day – principles, roles, ceremonies, and artefacts.

The Agile Manifesto

Four Values
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
Twelve Principles
  • 1. Satisfy customer through early and continuous delivery
  • 2. Welcome changing requirements, even late in development
  • 3. Deliver working software frequently (weeks, not months)
  • 4. Business and developers work together daily
  • 5. Build projects around motivated individuals
  • 6. Face‑to‑face conversation is the best
  • 7. Working software is the primary measure of progress
  • 8. Sustainable development (constant pace)
  • 9. Continuous attention to technical excellence
  • 10. Simplicity – maximise work not done
  • 11. Self‑organising teams
  • 12. Regular reflection and adjustment

Agile Frameworks

Scrum

  • Most popular Agile framework
  • Iterative (sprints)
  • Roles: Product Owner, Scrum Master, Team
  • Ceremonies: Sprint Planning, Daily Standup, Review, Retrospective
  • Artefacts: Product Backlog, Sprint Backlog, Increment

Kanban

  • Visual workflow management
  • Continuous delivery (no sprints)
  • WIP (Work In Progress) limits
  • Kanban board (To Do, Doing, Done)
  • Focus on flow efficiency

Extreme Programming (XP)

  • Engineering practices
  • Pair programming, TDD, continuous integration
  • Short iterations (1‑2 weeks)
  • Customer on‑site

Lean

  • Eliminate waste, deliver fast
  • Value stream mapping
  • Continuous improvement (Kaizen)
  • Respect for people

Scrum Roles

Product Owner (PO)

  • Defines product vision
  • Manages Product Backlog (priorities)
  • Ensures value delivery
  • Single point of contact for stakeholders
  • Accepts or rejects work

Scrum Master (SM)

  • Facilitates Scrum ceremonies
  • Removes impediments
  • Coaches team on Agile practices
  • Protects team from distractions
  • Ensures Scrum is followed

Development Team

  • Cross‑functional (devs, testers, designers)
  • Self‑organising
  • Size: 3‑9 people
  • Collectively responsible for delivery
  • No sub‑teams or hierarchy

Stakeholders

  • Anyone with interest in the product
  • Business owners, customers, users
  • Provide feedback and input
  • Not part of the Scrum team

Scrum Ceremonies

Sprint Planning

  • Start of each sprint (2‑4 hours for 2‑week sprint)
  • Set sprint goal
  • Select items from Product Backlog for Sprint Backlog
  • Estimate effort (story points / hours)
  • Output: Sprint Backlog, Sprint Goal

Daily Standup (Daily Scrum)

  • 15 minutes, every day
  • Three questions:
    • What did I do yesterday?
    • What will I do today?
    • Any blockers?
  • Not a status update for managers
  • For team synchronisation

Sprint Review

  • End of sprint (1‑2 hours for 2‑week sprint)
  • Showcase completed work to stakeholders
  • Demo working software
  • Gather feedback
  • Update Product Backlog based on feedback

Sprint Retrospective

  • After Sprint Review (1‑2 hours)
  • Team reflection
  • What went well? What could improve?
  • Identify action items for improvement
  • Continuous improvement (Kaizen)

Scrum Artefacts

Product Backlog

  • List of all desired features, improvements, fixes
  • Single source of truth (Product Owner owns it)
  • Prioritised (most important at top)
  • Refined regularly (Backlog Grooming)
  • User stories with acceptance criteria

Sprint Backlog

  • Items selected for the current sprint
  • Broken down into tasks
  • Owned by Development Team
  • Visible and updated daily

Increment

  • Working software at the end of sprint
  • Must meet Definition of Done (DoD)
  • Potentially shippable
  • Combined with previous increments

Definition of Done (DoD)

  • Criteria for completion
  • Code review done
  • Unit tests passed
  • Integration tests passed
  • Documentation updated
  • Accepted by Product Owner

User Stories

Format

As a [user role],
I want to [action],
So that [benefit].

// Example
As a customer,
I want to reset my password,
So that I can regain access to my account.

INVEST Criteria

  • I – Independent (not dependent on other stories)
  • N – Negotiable (details can be discussed)
  • V – Valuable (provides value to user)
  • E – Estimable (can be estimated)
  • S – Small (can be completed in one sprint)
  • T – Testable (has acceptance criteria)

Acceptance Criteria (Gherkin)

Given [initial context]
When [action is performed]
Then [expected result]

// Example
Given a user is on the login page
When they enter valid credentials
Then they are redirected to the dashboard

Agile Estimation

Story Points

  • Relative effort (not time)
  • Fibonacci sequence (1, 2, 3, 5, 8, 13, 21)
  • Factors: complexity, risk, effort
  • Planning Poker (team estimation)

Velocity

  • Average story points per sprint
  • Used for capacity planning
  • Calculated after sprint completion
  • Helps forecast future sprints

Kanban Principles

  • Visualise workflow – Kanban board
  • Limit WIP – reduce bottlenecks
  • Manage flow – monitor lead time
  • Make policies explicit – clear rules
  • Implement feedback loops – continuous improvement
  • Improve collaboratively – evolve experimentally
Kanban Board Columns
  • To Do – not yet started
  • In Progress – being worked on
  • Review – code review, QA
  • Done – completed

Agile Metrics

  • Velocity – story points per sprint
  • Burndown Chart – remaining work vs time
  • Burnup Chart – completed work vs time
  • Cumulative Flow – work in progress over time
  • Lead Time – time from request to delivery
  • Cycle Time – time from start to finish
  • Throughput – items completed per time
  • WIP – Work In Progress

Scrum vs Kanban

Aspect Scrum Kanban
Iterations Fixed sprints (1‑4 weeks) Continuous flow
Roles PO, SM, Team No required roles
Planning Sprint planning On‑demand
WIP Limits Implicit (team capacity) Explicit (per column)
Changes Blocked during sprint Allowed anytime
Metrics Velocity, burndown Cycle time, lead time

Common Anti‑Patterns

  • Blaming – focus on process, not individuals
  • Over‑committing – unrealistic sprint goals
  • Ignoring technical debt – accumulating debt
  • Not following DoD – half‑done work
  • Not attending ceremonies – missing standups
  • Waterfall‑Scrum – waterfall disguised as Scrum
  • Command and control – not empowering the team
  • Too many WIP items – context switching
  • No backlog refinement – unprepared sprints
  • Stakeholder absence – no feedback

Best Practices

  • Keep sprints consistent – same duration each sprint.
  • Refine backlog continuously – not just during sprint planning.
  • Estimate as a team – use Planning Poker.
  • Track velocity – for capacity planning.
  • Use Definition of Done – make it explicit.
  • Retrospectives are crucial – act on action items.
  • Daily standups are for the team – not for managers.
  • Keep ceremonies time‑boxed – respect timeboxes.
  • Visualise work – use physical or digital boards.
  • Limit WIP – avoid bottlenecks.
  • Automate where possible – testing, deployment, monitoring.
  • Empower the team – trust them to self‑organise.
  • Involve stakeholders – regular demos and feedback.
  • Focus on value – prioritise based on business value.
📌 Quick Reference
Agile Values: Individuals, Working Software, Customer Collaboration, Responding to Change
Scrum Roles: Product Owner (PO), Scrum Master (SM), Development Team
Ceremonies: Sprint Planning, Daily Standup, Review, Retrospective
Artefacts: Product Backlog, Sprint Backlog, Increment, DoD
Estimation: Story Points, Fibonacci, Planning Poker, Velocity
User Story: As a... I want... So that...
Kanban: Visualise, Limit WIP, Manage Flow, Continuous Improvement
← Back to All Cheatsheets