Agile One Pager
Principle behind
the Agile Manifesto
Our highest priority is to satisfy the
customer through early and
continuous delivery of valuable
software.
Visualization of top
priority items
Value based
prioritization
Pull system of work
assignment
Shippable SW after
each Sprint
Sprint Review
Business people can
change and re-prioritize
work not yet started at
any time
Product Backlog
grooming
Re-prioritization after
each sprint
Work released on
demand
Sprints (iterations)
Welcome changing requirements,
even late in development. Agile
processes harness change for the
customer's competitive advantage.
Deliver working software
frequently, from a couple of weeks
to a couple of months, with a
preference for the shorter
timescale.
Business people and developers
must work
together daily throughout the
project.
Build projects around motivated
individuals. Give them the
environment and support they
need and trust them to get the job
done.
The most efficient and effective
method of
conveying information to and
within a Development Team is
face-to-face conversation.
Scrum
Kanban / Lean
Highly collaborative
PO as VOC
PO readily available to
team on a daily base
XP
DSDM
Customers and
Developers work
together to plan
releases
Iteration planning
Iterations
Customer is part of the
Team
SM is only facilitator
Open work space
Self-organizing teams
Pairs evolve as needed
Demo/Acceptance after
each sprint
Build customer
feedback into each
iteration to converge on
an effective business
solution
MoSCoW
Develop iteratively in
Timeboxes
Involve the right
stakeholders, at the
right time, throughout
the project
Co-located teams
Co-located teams
Co-located teams
Daily Stand-Ups
Daily Stand-Ups
Daily Stand-Ups
2012 SCRUMstudy.com
FDD
Crystal
Early Victory
Client-Value based
features
Walking skeleton
Frequent Customer
feedback
Short ramp-up for
modeling
Re-calibration of the
release plan
Domain based model
fosters change
Frequent User
feedback
Short cycles with
complete features allow
for frequent change
Iterations
Increments (per
feature) <= 2 weeks
Iterations (1 or more
complete features
Easy access to expert
users
Client interaction during
processes #1 and #2
Frequent feedback from
end users
Frequent demos with
customer feedback
Process Miniature
makes sure team
members understand
the process well
Domain Experts
Class ownership
However, there is
Team leadership
Assignment of team
membership based on
expertise
Multiple Small teams
Joint design,
inspections etc.
However, a lot of
information sharing via
CMS
Team decides
improvement / changes
Co-located teams for
Crystal Clear
Osmotic
Communication
Daily Stand-Ups
Agile One Pager
Principle behind
the Agile Manifesto
Working software is the primary
measure of progress.
Agile processes promote
sustainable development. The
sponsors, developers, and users
should be able to maintain a
constant pace indefinitely.
Kanban / Lean
WIP limit
No fix release or
delivery dates
Limit of WIP forces
completion or work
packages
Scrum
XP
Working SW at the end
of each Sprint
No technical debt
TDD
Egoless software
Velocity
Iteration planning
Done criteria (Only
complete/done work
counts)
Sustainable,
predictable pace
Refactoring
DSDM
Deliver Good enough
early instead of
Perfect too late
Continuous Integration,
refactoring & building
often
FDD
Crystal
Walking Skeleton
Inspections
Automated Tests
(Unit) tests
Frequent Integration
-Blitz planning
Clearly defined
entry/criteria per
process
only completed work
counts
Domain Object Model
as base
Frequent updates
Incremental Rearchitecture
Continuous attention to technical
excellence
and good design enhances agility.
Simplicity--the art of maximizing
the amount of work not done--is
essential.
Small user stories
Small user stories
Small features
Continuous reevaluation and reprioritization
Continuous reevaluation and reprioritization
Focus on Client value
Good upfront design /
model
The best architectures,
requirements, and designs emerge
from self-organizing teams.
No team leader
Pair Programming
Team coding standards
Team consensus for
Domain Object Model
Small teams foster cooperation across
expertise boundaries
The 6 milestones per
feature allow for
frequent checks for
improvements
However, no reflections
are prescribed
At regular intervals, the team
reflects on how
to become more effective, and
then tunes and adjusts its
behaviour accordingly.
Team commits
Team member select
tasks
Retrospective Meetings
at the end of each
sprint
Retrospective meetings
at each iteration end.
Improving the process
is part of the
development.
2012 SCRUMstudy.com
Members of the team
empowered to make
decisions on behalf of
those they represent
without waiting for
higher-level approval.
Facilitated workshops
Side by side
programming
Reflection Workshop
