Agile checklist

For agile beginners: Follow the checklist, do Agile by the book. This will enable you to run your first
sprints successfully. Your success will facilitate to spread agile in your organization.
For agile intermediates: Use your common sense to tweak your processes and practices guided by this
checklist.
For agile experience experts: Use this checklist as your guidelines and safety belt in stressful
situations.

 This Agile checklist cannot give you everything you need, so don’t stop thinking for yourself and
adapt your project to the context.
 This checklist does not replace experience and practice.

Keep alive the basic principles of agile.

The procedures and practices in this checklist will help you
to reach these basic goals.

□ Focus on the features that business needs most (vision).

□ Deliver working software frequently (at least every 4 weeks).
□ Business and IT work together to complete all the work (collaboration and communication).
□ Improve continuously your software, processes, practices and team (feedback / inspect and adapt).
 Agile checklist

Agile enterprise picture

Agile enterprise
□ Project and product development starts with a vision associated with a customer need or direction.
□ IT & business visions and goals are aligned (IT vision in function of business).
□ The high level analysis and design explains the big picture of the project (not all the details).
□ The team vision and big picture is clear and visible for the team and leads to more informed
decisions by the team.

Date
06/12/2012
2/22
 Agile checklist

Release planning
At the start of any new project, you need to ask following questions to come to the core of the project.
Answer the questions in the right order, to focus first on the problem, than on the solution.
1. Why are we doing this? What is the desired business change? (= business drivers = requirements)
2. Who are the people that will use and benefit from this? (= target group = stakeholders)
3. How can we support them? (= target group needs = stakeholder needs)
4. What are the business activities or software capabilities that would support the needs of the
stakeholders? (= product features)

Techniques like workshops, interviews,

jobshadowing, questionnaires, actor maps,
personas, process flows, state diagrams,
interaction models, ... and examples, helps you
to get an answer on these questions. Use the
techniques that are valuable for your project,
but let it be fast and lightweight. So, no heavy
six months analysis and requirements-gathering
exercises that goes far too much into detail. But
just enough analysis to have a common vision in
your team. You can put all these information in
a high level analysis document, or just put the
big picture on the wall.
Get the right people in the room and ask them the right questions, and you will get the right answers on
your questions. On top, this will do wonders for collectively setting expectations about the project. The
right people include customers, stakeholders, team members or anyone directly involved in the project.
As a team member get inside your customer’s head and try to really understand what they need.
Put the business drivers on the wall in your workspace to let it serve as a reminder about what you are
working on and why. It helps you to drive the project execution towards delivering the right business
effects.

High level analysis = “just enough”

□ The focus is in first instance on the problem, in second instance on the solution.
□ Customers, stakeholders and team members are involved to clarify the ‘why’, ‘who’, ‘how’ and
‘what’ of the project.
□ All team members understand the functional big picture of the project.
□ The high level analysis contains “just enough” information to estimate and prioritize.
□ The business drivers are visible for the team.
□x

Date
06/12/2012
3/22
 Agile checklist

There is a subtle balance to be made when considering design and architecture. Writing huge
architecture documents that details every aspect of the design is pointless. Those documents never end
up being read and tend to be quickly outdated. If you would do no architecture at all, you risk ending up
with a big ball of mud and no coherence in your design. So you should do just enough architecture to
have a common vision in your team and have a good overview of technical risks.
To understand the significant elements you don’t need complex UML
tools. Drawing some diagrams at the whiteboard or using post-its on a
flipboard is often quicker and invites a more collaborative approach. The
4C’s are used to guide you while looking at the architecture. Sometimes
it is hard to know what is significant and what is not significant. A good
question to ask in this case is “How easily can I change a certain
technology choice?”
What does it mean to have good foundations for our architecture? What
we really want to know is wether or not our architecture will be able to
handle the different kinds of business requirements. We can do this by
going over some different kinds of user stories and check if we considered
everything. However just looking at diagrams will never be enough. The
only way to validate an architecture is to actually implement different
kinds of user stories. When we notice during development that our
architecture is not good enough, the architecture should be adapted. It is
never set in stone.

A common problem is that a nice architecture has been set up but the development team doesn’t know
anything about it. Just as important as providing good foundations is making sure the entire team shares
the same vision. That’s why architecture is best done in collaboration with the entire team. If there is
an official architect he should act as a facilitator and a teacher during these collaborative sessions.

High level architecture = “just enough”

□ The team understands the significant elements making up the architecture.
□ Context: the new system fits in the existing IT landscape.
□ Containers: the involved servers and used technologies are clear (high-level).
□ Components: the system is made up of components.
□ Classes: the classes are relevant to a typical story.
□ The architecture provides good foundations and vision to move forward.
□ The team collaborates on the architecture and shares the same vision.
□ The architect acts as facilitator and teacher. He is also involved in the actual development of the
project.
□ The architecture is validated by implementing user stories.

Date
06/12/2012
4/22
 Agile checklist

After the “just enough” analysis and architecture, you can start making the product backlog. The
product backlog is the to do-list of things you need to deliver for your project. It contains all the
functionalities your customer will want to see in their
software.

Do not forget to add in the product backlog the non

functional requirements (performance, ...),
housekeeping tasks (ongoing improvements, ...),
infrastructure tasks (technical setup, ...) and
deployment tasks (documentation, ...).

A great way to visualize your product backlog is by

user story mapping. You have a big picture of the full
scope of your project, missing functionalities and
dependencies between user stories becomes clear. It
can also help you to transfer your high level analysis
into your product backlog. Make your user story
mapping dynamic and follow up your project.

Product backlog
□ The full scope of the project is listed in the product backlog (in modules, epic stories and user
stories).
□ The product owner understands the purpose of all product backlog items.
□ The product backlog is kept up-to-date and always contains the latest information.

Talking about project risks is important to let the team

members think on what you need for the success of the project.
And you need to do it at the beginning of your project. There is
also something good about sharing and discussing your fears
with others. It gives the team a chance to bond, share war
stories and just learn from each others’ experiences. So,
identify the risks of your project now!

A nice way to identify risks is by risk storming. You identify the

risks and prioritise them according to impact and probability.
Each team member can put a post-it on one of the previous
diagrams describing his concern. The color of the post-it
(green, yellow, red) indicates the level of impact and
probability. To tackle the risks we make sure high-risk and high-
value user stories are done as soon as possible.

Risks
□ Risks are identified by the team members.
□ There is a prioritised overview of risks and a way to mitigate them.

Date
06/12/2012
5/22
 Agile checklist

Estimating and planning are critical to the success of any software development project. Because
estimations and plans guide our investment decisions. How much people do we need during a given
period? Is the project on track to deliver the functionalities that users need and expect? When will the
project be done?
A fun and effective way to estimate the product backlog is by planning poker. A user story is discussed
and each estimator selects the card that represents his or her estimate. All cards are shown at the same
time. If everyone’s estimate is more or less the same, the estimate is kept. If there are differences, the
estimates are discussed and the process repeated until agreement on the estimate is reached.
Estimates can be done in mandays, but a faster
and more effective way is by story points. Story
points are a relative measure of the size of a
user story. A user story estimated as 10 story
points is twice as big, complex or risky as a user
story estimated as five story points. Story points
are purely an estimate of the effort of the work
to be performed.
But, estimating is difficult. High level estimates
at the start of a project are far less accurate
than those given later (cone of uncertainty).

Estimating size
□ Estimates are in relative sizing (story points).
□ Estimates are collaborativily done by team members who will execute the project.

The purpose of prioritizing the product backlog is to generate more business value, to focus on the
features that business really needs. This ensures the customer that an agile team will do the most
important thing first because there is rarely enough time to do everything. Prioritizing sorts the product
backlog items into an initial order. These items can then be moved forward or back and allows customers
to change plans given the most recent knowledge.
Try to come out with several releases for your full product backlog. A release is a logical grouping of
user stories that makes sense to the customer, something worth bundling up and deploying. It helps the
customer and team decide how much must be developed and how long that will take before they will
have a releasable product. The sooner the product can be released, the sooner the enterprise will begin
earning a return on their investments in the project.

Prioritizing
□ The customer prioritizes the user stories by return on investment, business value, risks and cost of
development (and maintaining).
□ The most important factor to prioritize is the financial value: the amount of money earned having
the features (return on investment) or the amount of money saved when not having them.
□ The customer prioritizes the product backlog together with other stakeholders.
□ The product backlog items are segregated from must-have to nice-to-have features. The must-have
features are planned in release 1, the nice-to-have features in the last release.
□ The full product backlog is divided into several, frequent releases.

Date
06/12/2012
6/22
 Agile checklist

After estimating and prioritizing the product backlog, planning can start. As we discover things during a
project, the planning becomes more important than the plan. Therefor, agile planning is nothing more
than measuring the speed a team can turn user stories into working, production-ready software and then
using that to figure out when they’ll be done.
The team speed is a guess at the start of a project (initial team velocity). The more sprints you
execute, the more realistic the plan will become. In the beginning of your project, the team speed is
going to fluctuate, so don’t panic. But after three or four iterations, the speed should start to settle
down, and an idea is get of how fast the team can go.
To give us a rough idea about delivery dates, we take the total effort for the release/project, divide it
by our estimated initial team velocity, and calculate how many iterations we think we’ll require to
deliver our release/project. This becomes our release planning.

Initial release plan

□ Each release starts with a release planning meeting to align all team members and stakeholders.
□ A buffer (feature and/or time) is added in the release planning.
□ The initial plan is presented to management and customer, but set the right expactations and make
them aware of the fact that the plan can go better or worser.

There are four forces at work during a project: scope,

budget, time and quality. Giving in to one means taking
something away from the others and striking the right
balance between them takes work.
There are those who believe quality can be sacrificed in the
interest of time. They are wrong. Any short-term gain in
speed, resulting from a reduction in quality, is a false and
temporary illusion. So quality needs to be fixed and always held to the highest standard.
Time (release date) and budget (resources) is in most of the projects also a fixed force. So there is only
one force left to bend on a project: scope. Being flexible around scope is how agile projects maintain
the integrity of their plans.

Date
06/12/2012
7/22
 Agile checklist

Project execution
Iterations represent the execution heartbeat of the project. The goal of those timeboxed iterations is to
deliver working software frequently. A big difference with traditional development, is that analysis,
design, coding and testing are continuous activities, they never end. That means these activities cannot
exist in isolation anymore.

Timeboxed iterations
□ Iterations are of a consistent fixed length, ideally 2 weeks (max 4 weeks).
□ Within the iteration everything is done to deliver a deployable product: analysis (for next
iteration) + testing + design + coding + anything else.

Sprint backlog
□ The scope of the iteration is listed in the sprint backlog.
□ The sprint backlog contains the highest priority user stories.

Deployable product
□ The delivered piece of software works end-to-end and is tested.
□ The product increment is deployable on a testenvironment.

Date
06/12/2012
8/22
 Agile checklist

Setting up a visual workspace is great! You can put the most interesting information of the project on
your project wall (= information radiators).
By using a taskboard, you can see what’s coming, what’s going and what’s finished altogether in one
quick glance. It enables you to work with greater clarity and focus. You will never be at a loss for what
to do next or where you can add the greatest value.

Taskboard
□ The sprint backlog is made visible on the taskboard.
□ The taskboard is maintained by the team.
□ The taskboard makes iteration progress and impediments visible.
□ The taskboard makes clear who’s working on what.
□ The taskboard is used to display bugs.

Definition of “done”
□ It is clear what “a user story is done” means for the team.
□ The team respects the definition of “done”.
□ No story points are count when a user story is “not done”.
□ The definition of “done” is visible for the team.

Sprint burndown
□ The burndown chart tracks how much work has been done and
remaining for an iteration.
□ The team updates the burndown chart every day.
□ The burndown chart is visible for the team.

Date
06/12/2012
9/22
 Agile checklist

In its simplest form, agile planning is nothing more than measuring the speed a team can turn user
stories into working software and then using that to figure out when they all be done.

Team velocity (= Throughput)

□ The amount of work completed (number of story points) is measured each
iteration.
□ The team velocity only counts user stories that are “done”.
□ The team velocity takes care of most estimation inaccuracies (equalizer).
□ The team velocity is visible for the team.

Release burnup
□ The release burnup chart tracks the number of story points done and
remaining for the release.
□ The release burnup presents also the discovery of new user stories.
□ The release burnup is visible for the team.

Agile project planning: dealing with reality!

□ The Agile plan is updated quickly as things change.
□ The Agile plan is flexible about scope because they are business value driven (fixed date).
□ If the customer refuses to be flexible about scope, several options are possible: push out the date,
change priorities or add resources (initially slows down).

Date
06/12/2012
10/22
 Agile checklist

Analysis practices
To deliver working software frequently, analysis needs to give what is needed, just when it is needed. By
making the deep-dive analysis just in time, analysis gets done with the latest and greatest information.
On top, customer proxies and business have the chance to learn and get more insights during a project
and a lot of rework is avoided.
The deep-dive analysis is written down into user stories. A user story is a brief statement of intent that
describes something the system needs to do for the user.

User story
□ A user story contains a little piece of business value (end to end).
□ A user is discussed between business and the team (conversation).
□ A user story is written in simple terms, understandable for business and the team.
□ A user story is a work document, not documentation.
□ A user story is elaborated just-in-time.
□ A user story is small enough to fit in a single iteration.
□ A user story contains a story sentence, acceptance criteria, situation in the big picture,
implementation details and a test design.

INVEST in good user stories:

Agile teams spend a significant amount of time in discovering, elaborating and understanding user
stories. This is good, because understanding what the real objective for the code is, is the hardest part.
Therefore, user stories needs to be:
o Independent: Maybe the hardest thing to achieve. Try to develop, test and deliver a user story
on his own. Therefore, it can also be independently valued.
o Negotiable: A user story is not a contract for features, but rather a placeholder for requirements
to be discussed, developed, tested and accepted, negotiable between business and the team.
o Valuable: Each user story represents business value and provides end-to-end functionality (slicing
through all the layers of architecture).
o Estimable: Each user story contains enough information to be estimated by the developers.
o Small: A user story can be implemented in an iteration. If a user story is too big, split the story
into smaller stories. Smaller user stories provide more agility and productivity due to increased
throughput and decreased complexity.
o Testable: Acceptance criteria and a test design are added in the user story to minimize
interpretation problems and to know when the software is working.

Date
06/12/2012
11/22
 Agile checklist

Testing practices

To deliver working software frequently, testing will have to follow development.You can’t afford to wait
until the end of the project to see whether everything works.You are going to have to maintain the
health and integrity of the software from day one of the project. That means the team will write
automated tests to find out whether the code (still) works, in minutes rather than hours or days.
The focus needs to be in first instance on unit tests
because there are many benefits of writing unit tests
against the code. It gives instant feedback when
changes are made to the code and a unit test breaks.
It reduces debugging time greatly because the problem
is exactly known when a unit test fails. The cost of
regression testing is dramatically lower because
retesting everything manually is not necessary when
releasing every time. And finally, it gives more
confidence when deploying into production knowing
there is a suite of autometed tests backing you up.
And testers can focus on edge cases instead of wasting
time on trivial problems.
Agile testing does not consist of testing only software,
but also requirements, acceptance criteria, ... What
use is it to have a program without bugs, if it does not
fulfill the needs of the end user? Finding defects is not
the only intent. Early testing is good to prevent
defects and high fixing costs. Getting early feedback
from the end user, will focus on the main goal of agile:
deliver business value to the end user.

Agile testing
□ Automated tests are written to get as fast as possible feedback on the software.
□ There are more unit tests than integration tests written, and more integration tests
than UI tests.
□ Each user story is tested into detail during the same iteration of implementation.
□ Defects are fixed as quickly as possible (in the iteration).
□ A user story is tested to the satisfaction of the customer.
□ The customer who gave the requirements, is testing from the start (early feedback).
□ The real end user explores the application from an early stage in development and gives
feedback.
□ End user testing is possible on a specific test environment with the necessary test data.

Date
06/12/2012
12/22
 Agile checklist

Engineering practices

To deliver working software frequently, engineering practices need to be rock-solid.There is no time to

continuously go back and fix buggy code. It has to work immediately. That means technical excellence,
well-designed software, limited technical debt, simple development process, great discipline, easy
software maintainability/extensibility and completely integrated code.

Building, integrating and deploying software can be fast and easy by continuously integrating the
changes of developers throughout the day. In this way, bugs are squashed early, making changes has a
lower cost and deployment will be with confidence. The less human involvement you need in this
processes, the better.

Continuous integration
□ The team acts like it is in production from day one of the project.
□ An (open) source code repository (like Subversion) is used.
□ A check-in process (latest source from repository, ...) is established.
□ The code is integrated in small chunks multiple times per day.
□ An automated build system (like Jenkins) is used.
□ A broken build is always fixed immediately.
□ Failing tests are not comment out.

Making the shift from up-front design to incremental design can be a big challenge. Incremental design is
simply taking time to improve the design of the software in small steps (baby steps) as you go. Design
improvement becomes part of every developer’s day. It’s done on every user story and is not something
left until later. Working this way, developers think about the design of the software as they write tests,
as they implement the code to pass those tests, and before they check in their code.
Making a design for now does not mean developers have to be deliberately shortsighted. The team can
bear in mind the upcoming user stories when making design decisions. But rework often improves design.
Each time the design is reworked, it is refined and becomes more malleable.

Incremental design
□ A limited time is spend on thinking about design without producing working software.
□ A design is made for now and is as simple as possible for current needs (bearing in mind
upcoming user stories).
□ Ideas are proven by implementing them.
□ A whiteboard is used during design session.

Date
06/12/2012
13/22
 Agile checklist

Refactoring is a way of systematically paying down the technical debt. It is a way of incrementally
improving and maintaining the design of existing code to improve the quality and maintainability
without changing its behavior. Refactoring is the necessary act of putting code in the right place, where
other developers can find it quickly and easily. It’s keeping code organized and decluttered. Refactoring
also means well-named methods and variables that improves the readability and maintainability of the
code base. When you refactor aggressively, you don’t slow down near the end of a project, you speed
up! Because adding new code and fixing bugs will be better, faster and cheaper.
Developers need to do refactoring, or they can end up with the same code in several places, which take
more effort to maintain. Refactoring is not the aesthetic organization of the code, it is basic
housekeeping.

Refactoring
□ Refactoring is continuously throughout the day (small steps and improvements).
□ It is permitted to refactor anywhere in the code base.
□ Methods and variables are renamed to make the code base easier to read and understand.
□ Big refactorings are rare and need to be estimated and prioritized.

Test Driven Development (TDD) is a more advanced coding technique that builds on unit testing and
refactoring. It uses really short development cycles to incrementally design software. The purpose of
TDD is to build only what is needed while testing that it works. This leads to a much easier code base to
maintain and modify. With less code comes less complexity. And with a simpler design, making changes
and modifications becomes a lot easier.

Test Driven Development (TDD)

□ The focus is on one little problem and how to tackle this incrementally by getting instant
feedback.
□ Red: a failing unit test is written.
□ Green: just enough code is written to get the test pass.
□ Refactor: code is cleaned up (eliminate redundancy).

Date
06/12/2012
14/22
 Agile checklist

Nobody owns the code on an agile project. It belongs to the team. That means anyone, at any time, is
expected and encouraged to make any changes necessary to complete the work they are doing.
Readable code helps practicing collective code ownership. Developers need to write code that is easy to
understand by anyone else on the team and is also self-explanatory to those maintaining the code in
years to come. When the words used in your software don’t match those used by business, you can get
into all sorts of trouble. In agile development, it is the developer’s job to speak the language of the
user, not the user’s job to speak the language of technology (= ubiquitous language).
Collective code ownership is easier when the team follows a consistent approach to design and
coding standards. The team simply needs to establish a ‘house style’ that everyone agrees to follow.
Once the team has a consistent style, their code is more readable, and less time is wasted on
reformatting code to personal taste.

Collective code ownership

□ Developers do not pick bits of the code base that they consider as their own.
□ Any developer can edit any piece of code.
□ Coding standards exist and are applied by the team.
□ Ubiquitous language is used in code and tests.

Pairprogramming is two developers working together at the same computer, solving the same problem.
Each person plays an active role in creating the software. The person activily typing is known as the
driver. The partner is the navigator who looks ahead to consider next steps and potential pitfalls. Pairs
swap fluidly between these roles.
By pairprogramming the code will be of a higher quality because it is constantly being reviewed. Also,
good practices and coding standards are shared more widely amongst the team which leads to more
readable code. And finally, two developers know more than one developer.
You can go even further with your team and swarm. Swarming means working and focus with the entire
team on one and only one story at a time.

Pair programming
□ Pair programming is done in a pragmatic way.
□ One developer from each pair swaps out at least every day.
□ The driver is explaining what he is doing and why.
□ Pairs are always open to suggestions from each other.
□ The roles within a pair switches every 15 minutes (ping pong programming).

Date
06/12/2012
15/22
 Agile checklist

Agile team and roles

An agile team can serve their customer from end to end, called a cross-functional team. That means
having the necessary skills and expertise on your team to take any feature your customer would need
and be able to deliver it fully. That means generalists, people who are comfortable doing a wide variety
of things. For developers, that means coders who can walk the entire stack, front end to back end. For
analysts and testers, that means being comfortable doing analysis and testing.

Do’s:
Listen really to each other (respectful).
Ask open, clarifying questions. Agile team
Focus on solutions.
Build consensus and agreement in the team. □ All team members sit together (co-location).
Give positive, constructive feedback. □ Entire team is responsible for reaching the team
Foster a culture where it is OK to learn.
vision and goals (shared ownership).
Create learning opportunities.
Trust the team to get the job done. □ Team members help each other out.
Fix problems on the spot. □ All team members are 100% dedicated.
Celebrate the success of every release.
□ Everyone is doing the activity (efficiently) that
Dont’s: advances the team goals.
Do not ask criticizing questions.
Do not sit back and wait for orders. □ Communication is face to face.
Do not get emotional, speak about facts. □ Everyone helps in avoiding surprises and traps.
Do not be stubborn.
Do not assume, just ask. □ Team is smaller than 10 members.
Do not drag on with conflicts. □ Team works at a sustainable pace.
Do not blame each other.
Do not critize for mistakes.
Do not become complacent.
Do not be protective over what you see as ‘your’ stuff.

Date
06/12/2012
16/22
 Agile checklist

Agile projects fight hard for customer engagement. Because, how can teams be expected to build the
necessary, innovative products if the very people they are building them for aren’t part of the process?
That is why an engaged customer is necessary for any successful agile project. Engaged customers are
those who show up to demos, answer questions, give feedback, and provide the guidance and insight
necessary for the team to build compelling software. They are core-members of the team and full-on
partners during delivering.

Product owner
□ Product owner drives the project from a customer point of view.
□ Product owner has an overall product vision (short and long term).
□ Product owner decides what gets build and sets the priorities.
□ Product owner is empowered to take decisions.
□ Product owner is in constant communication with customers in order to speak with one
voice.
□ Product owner ensures that the team only works on the most important user stories.
□ Product owner helps the team by clarifying the requirements.

On site customer
□ On site customer is a functional domain expert.
□ On site customer helps the team by giving detailed input.
□ On site customer ensure that the user stories cover the requirements.
□ On site customer helps the team with functional testing.

Scrum master
□ Scrum master ensures that the project objectives are realized.
□ Scrum master navigates the team through the iterations.
□ Scrum master removes impediments and monitors risks.
□ Scrum master communicates the state of the project and consult all stakeholders of
the project.
□ Scrum master makes sure that the agile principles are understood and respected.

Date
06/12/2012
17/22
 Agile checklist

Customer proxy
□ Customer proxy represents the customer/product owner within the team.
□ Customer proxy analyses the customer needs in detail (user stories).
□ Customer proxy uses a collection of tools and techniques to help create a compelling
user experience.
□ Customer proxy ensures the review process of the user stories before implemented.
□ Customer proxy tests the implemented user stories and confirms stories work as
expected.

Coach developer
□ Coach is the technical mentor of the team.
□ Coach coaches developers in engineering practices, design and architecture.
□ Coach ensures that any technical impediments get resolved.
□ Coach writes code and tests like all the other developers.

Developer
□ Developer turns user stories into working software.
□ Developer defines the technical design and architecture.
□ Developer writes code and automated tests for these code.
□ Developer tests the implemented solution and deliver the product as agreed.
□ Developer is responsible for the quality of the implemented solution.

Operations
□ Operations ensure the software gets deployed on a test environment
after every iteration (automated process).
□ Operations ensure that the test environment is as close as possible
to the production environment.

Date
06/12/2012
18/22
 Agile checklist

Agile meetings
Each iteration consists of a series of meetings. This cyclical series of meetings delivers the reliable beat
in a project. Iterations incorporate 5 key meetings: sprint planning meeting, kick-off, daily scrum, demo
and retrospective.

Sprint planning meeting

□ The sprint planning meeting takes place before each iteration.
□ Product owner, on site customer, customer proxies, scrum master and at least 1
developer participate in the meeting.
□ Customer proxies present the user stories of the next iteration.
□ User stories are prepared and reviewed before presenting them on the sprint planning
meeting.
□ All attendees understand the purpose of each presented user story.
□ Product owner and attendees approve on the acceptance criteria and content of each
user story.
□ Product owner is satisfied with the priorities.
□ The sprint planning meeting takes maximum 90 minutes.

Date
06/12/2012
19/22
 Agile checklist

Kick-off
□ The kick-off takes place on the first day of each iteration.
□ All team members participate in the meeting (product owner on demand).
□ Customer proxies present the (approved) user stories of the next iteration.
□ The team has a clear picture of the user stories that needs to be implemented in the
upcoming iteration.
□ User stories are re-estimated (in case this helps).
□ The team commits on delivering an achievable amount of user stories (according to
team capacity, average throughput and planning risks).
□ The sprint planning meeting takes maximum 90 minutes.

Daily scrum
□ The daily scrum takes place every day on the same time.
□ The daily scrum takes place in front of the taskboard (standing).
□ All team members and product owner participate in the meeting.
□ Each team member answers three questions: What did you do yesterday? What will you
do today? Are there any impediments on your way?
□ Iteration progress is reported to the whole team.
□ Problems and impediments are surfaced.
□ Replies are kept short and sweet.
□ Daily activities are planned and coordinated.
□ The daily scrum takes maximum 15 minutes.

Date
06/12/2012
20/22
 Agile checklist

Demo
□ The demo takes place on the last day of each iteration.
□ All team members, product owner and stakeholders participate in the meeting.
□ Developers demonstrate the implemented user stories (working software, no ppt).
□ Only user stories completely ‘done’ are demonstrated.
□ The demo is a working session, it is about getting new ideas.
□ Feedback is received of any incomplete items.
□ Product owner validates and accept (or not) the user stories of each sprint.
□ The demo takes maximum 30 minutes.

Retrospective
□ The retrospective takes place on the last day of each iteration.
□ All team members and/or product owner participate in the meeting (no managers).
□ Actions of the previous retrospective are checked.
□ Data is gathered of what went well and what can be improved in the team.
□ The ‘why’ of the gathered data is discussed.
□ The retrospective is focused on the process and practices, not on the people.
□ The facilitator makes an effort to ensure all team members participate.
□ The retrospective is not a complaining session.
□ Concrete improvement actions (SMART) are formulated on key issues (inspect and
adapt).
□ Commitment of the team is taken on these actions (continuous improvement).
□ The retrospective takes maximum 90 minutes.

Date
06/12/2012
21/22
 Agile checklist

Date
06/12/2012
22/22