back to notes

The Agile Checklist Manifesto

The Agile Checklist Manifesto
APRIL 18, 2014 COLLABNET VERSIONONE

Airline pilots use a checklist to clear their planes for takeoff. In an experiment Dr. Pronovost, a critical care specialist at John Hopkins, used the checklist strategy to attack just one common problem in the I.C.U., infections in patients with central intravenous lines.
Dr. Atul Gawande is the author of The Checklist Manifesto: How to Get Things Right. He is a MacArthur Fellow, a general surgeon at the Brigham and Women’s Hospital in Boston, a staff writer for The New Yorker, and an assistant professor at Harvard Medical School and the Harvard School of Public Health.
In his review of The Checklist Manifesto book, famous writer Malcolm Gladwell states “Although the book is written by a surgeon …. it is really relevant to how professionals deal with the increasing complexity of their responsibilities…It has been years since I read a book so powerful and so thought-provoking.” No wonder, the book is a New York Times, Wall Street Journal, USA Today, Entertainment Weekly, Washington Post, Los Angeles Times, Boston Globe, and San Francisco Chronicle Bestseller.
The important point Dr. Gawande is making is that the complexities of professional work in the 21st century may be best handled by the simplest solution of checklists. The counterpoint usually comes in two flavors:
· My job is too complicated (or too important) to reduce to checklists – an argument by cynical surgeons that Dr. Gawande ran into. This argument is easily refuted with the success Dr. Gawande’s checklists have enjoyed in hospitals.
· Checklists reduce my flexibility, creativity, spontaneity; or they are too bureaucratic. The argument can be refuted by recognizing that any tool can be misused. Rigidly enforced, top-down, heavy-handed, compliance-oriented, slavishly-followed checklists will indeed create problems; but highly customizable checklists developed by professionals and teams of professionals doing the work, supported by appropriate tool, and used by those empowered professionals can be very helpful. These kinds of smart checklists will take the drudgery and errors out of complex work, and thus, freeing up time for creative work.
As incisively reported by Robin Marantz Henig in her New York Times article, checklists work really well because ”In an age of unremitting technological complexity, where the most basic steps are too easy to overlook and where overlooking even one step can have irremediable consequences, something as primitive as writing down a to-do list to “get the stupid stuff right” can make a profound difference.”
I have been using checklists in my own agile coaching, training, consulting engagements: travel checklist, logistics checklist, preparatory homework checklist, follow-up checklist, etc. Overlooking one critical step has proved damaging and harmful (at least to me and sometimes to my clients), and my checklists have been the saviors. They unburden me and my clients from having to remember stuff or not miss the obvious in the frenzy of many things swirling around us. Life becomes more relaxed, and error rate and goof-ups go down dramatically.
Most of us working in agile development or agile management are neither airline pilots nor surgeons, but we deal with complex projects involving many people and teams, and lots of rapidly changing details where the devil lurks. Simple, customizable checklists, in my experience, are highly effective in slaying the complexity devil.
I will now present several examples of checklists applicable at the level of individual agile team members as well as agile teams. Each checklist contains a number of items (such as tasks, tests, steps, options, questions) with a role assigned to each item (task, test, and step). A checklist may or may not imply any order for items in it, or it may include a built-in workflow. I recommend you review, customize and try the checklists presented in this blog, and then relentlessly inspect and adapt them, i.e., make them work for you with fine tuning and revisions based on your own experience. If a task in a checklist is not applicable in your specific situation, you are free not to do that task with a reason that you can explain to yourself and to your team members. If a specific task quite often need not be done or is missing in a checklist, the checklist itself should be revised (inspect and adapt) by deleting the unneeded or adding the missing task in the checklist. You will be a lot more effective that way instead of trying to recall from your memory without any checklist all the tasks you may have to do (and then missing at least some, or a lot, or them).
User Story Checklist
Table 1 shows a checklist of typical tasks and tests in a user story. This should help a cross-functional agile team to pay attention to all these tasks and tests and not miss any work for the story in order to complete it and get it accepted by the product owner. If a story requires multiple design and code development tasks and multiple acceptance tests, more tasks and tests can be added to that specific story than shown in Table 1. Some tasks in Table 1 are optional, and may not be needed for a specific story.
Table 1: Tasks and tests in User Story Checklist


Defect Checklist
Defects found, especially outside a sprint such as in production, can be logged with the following checklist of tasks and tests.
1. Task: Log the defect with steps to reproduce the defect: QA tester
2. Task: Analyze and debug the defect: Developer
3. Task: Fix the defect: Developer
4. Task: Specify the test to verify the defect: QA tester
5. Test: Execute the test to verify it: QA tester
6. Task: Close the defect which has been verified as fixed: QA tester
Epic Breakdown Checklist
This checklist is based on the work done by Richard Lawrence where he recommends 9 patterns that you should try to use to break down an epic (a large story or feature) into smaller user stories. I have listed these 9 patterns as options below. A customized checklist augmented with a brief example for each pattern suitable for your organization will be very handy and effective when it comes to breaking down epics into stories.
• Option 1: Workflow Steps
• Option 2: Business Rule Variations
• Option 3: Major Effort
• Option 4: Simple/Complex
• Option 5: Variations in Data
• Option 6: Data Entry Methods
• Option 7: Defer Performance
• Option 8: Operations (e.g., CRUD)
• Option 9: Break Out a Spike
Sprint Planning Readiness Checklist
This checklist consists of a list of preparatory tasks that should be completed before starting a Sprint Planning Workshop or Meeting. These tasks should be completed ideally one timebox ahead, i.e., in parallel with the previous sprint execution. Completion of these preparatory tasks will help ensure a highly effective and productive sprint planning workshop, which is a time-boxed event (1/2 day for a two-week sprint or one day for a four-week sprint).
1. Task: Define the Agile team, its members and their roles/responsibilities: ScrumMaster
2. Task: Draft the key objectives for the upcoming Sprint: Product Owner
3. Task: Define and create the project hierarchy in Agile Project management (APM) tool, and make sure the members of the Agile team have the right role assigned on the project: ScrumMaster working with APM tool administrator
4. Task: Create the Sprint backlog in APM tool: Product Owner working with Business analysts: Epics, stories (preferably satisfying the INVEST criteria, Defects, Spikes, Maintenance work, porting work, certification work, Regression testing, System testing, Performance testing, etc.
5. Task: Explain and clarify the sprint backlog to team members for the upcoming sprint by conducting one or more sessions one timebox ahead, i.e., sprint work done in a pipeline mode (see details in my blog on Is Your Sprint Pipeline Running Well?): Product Owner.
6. Task: Calculate agile capacity for the team and each team member for the upcoming sprint (for capacity-based sprint planning – see details in my blog on agile capacity calculation): ScrumMaster working with each team member
7. Task: Prepare the preliminary rank order of backlog items based on business value (Optional): Product Owner
8. Task: Make sure all IT environments are in place: ScrumMaster working with IT staff: Development, QA, build machine, continuous integration server, software licenses, test data, any special hardware needed
9. Task: Review the Sprint Ready checklist (see below) and take necessary actions so the Agile team will be 100% ready to start the sprint as soon as the Sprint Planning Workshop is over: ScrumMaster.
10. Task: Complete all logistical arrangements for Sprint Planning Workshop (venue decided, attendees identified and invited, workshop material arranged, food ordered, etc.): ScrumMaster
Sprint Planning Workshop Checklist
The checklist shown in Table 2 consists of a number of tasks (Tasks T1 through T14) to be completed during a Sprint Planning Workshop. Rough time estimate for each task is indicated for a typical three-week sprint planning being done for the first time. With process maturity, experience and well-jelled teams, this planning time should come down to ½ day for two-week sprint planning to 1-day for four-week sprint planning.
Table 2: Sprint Planning Workshop Checklist


Sprint Ready Checklist
This checklist consists of a set of tasks that must be completed before a sprint should start and can run smoothly. If there is major incompletion of any of these tasks, it would be premature and risky to start a sprint, as it will experience obstacles, hick-ups, delays and impediments.
1. Task: Sprint objectives are well defined: Product Owner
2. Task: Full inventory of all work items is available, and all tasks and tests in stories of the sprint backlog are properly defined and have proper estimates: Product Owner, ScrumMaster
3. Task: Acceptance tests for each User story are well defined: Product Owner, QA tester
4. Task: All Agile team members are identified, their roles defined and necessary training completed or plans made: ScrumMaster
5. Task: Individual and total capacities and Individual and total estimated efforts match (for capacity-based planning): ScrumMaster
6. Task: Various standards (coding, testing, documentation, build, user interface, compliance, etc.) for your project are defined and easily available: ScrumMaster, Team Leads
7. Task: All IT environments, infrastructure and test sets required for the Sprint are available: ScrumMaster and IT staff
8. Task: Work is distributed evenly across all members of Agile team (load balancing done): ScrumMaster
9. Task: All stories in the Sprint are linearly rank ordered: Product Owner with Team
10. Task: Sprint Done Checklist is well defined: Product Owner with Team
11. Task: Any remaining small tasks that must be completed to reach 100% Ready state are documented (and are not show-stoppers): ScrumMaster
Daily Scrum Checklist
This checklist consists of a set of tasks for each individual member and also for ScrumMaster. See specific details in my blog on Daily Scrum.
1. Task: Ensure that the Daily Scrum room venue and timing is the same for every day in a sprint: ScrumMaster
2. Task: Invite each member of the Agile team for Daily Scrum on a standing basis for every day throughout the sprint duration: ScrumMaster
3. Task: Prepare for the Daily Scrum meeting ahead of the actual meeting: Each team member
1. Report on the status of yesterday’s tasks against the plan for yesterday
2. Present the plan for today’s tasks
3. Present what do I need from any other team members to do my work
4. Present any impediments on the horizon that could block my work
4. Task: Present key information radiators from APM tool, such as burn-down and burn-up charts, Cumulative Flow diagram, Impediments being worked on: ScrumMaster
5. Task: Capture any risks, issues, and decisions coming out of Daily Scrum: ScrumMaster
Sprint Done Checklist
This checklist consists of a set of tasks that must be completed before a sprint can be declared successfully “Done”. This list ensures unambiguous completion of a sprint.
1. Task: Acceptance testing completed: QA testers
2. Task: Defect fixing work completed: Developers
3. Task: Fixed defects are verified and closed by QA members of the agile team: QA testers
4. Task: The list of defects to be pushed out to the next sprint is finalized: Product Owner, ScrumMaster, Team
5. Task: All technical documentation is completed: Technical leads
6. Task: All user documentation is completed and is ready to be released to sprint users: Tech writer
7. Task: Sprint release can be delivered to interested customers and users ready to receive it: ScrumMaster
8. Task: All data in APM tool is up-to-date and consistent with the completion (Done) state of this sprint: ScrumMaster and Team
9. Task: Sprint delivery has met the Sprint objectives: Product Owner
10. Task: Sprint release is accepted by the Product Owner: Product Owner
Sprint Retrospective Checklist
This checklist consists of a set of tasks that must be completed during Sprint Retrospective session (typically a 1 to 2-hour timebox) so that the team can develop a SMART action plan that it can act on during the next sprint to improve its own agile process in a specific way. See specific details in my Sprint retrospective blog.
1. Task: Determine up to 3 top things that worked really well, and the team wants to continue: Team
2. Task: Determine up to 3 top things that were most problematic, and the team wants to discontinue or change: Team
3. Task: Determine up to top up to 3 impediments and their root causes: ScrumMaster
4. Task: Capture and present key statistics, such as initial capacity of the team, planned vs. actual velocity, scope change. Most of these are reports generated by APM tool: ScrumMaster
5. Task: Develop 3 to 5 specific action items as part of the Specific, Measurable, Achievable, Realistic, Time-bound (SMART) action plan to improve the agile process: Team
6. Task: Convert the SMART action items into Stories in APM tool, and assign them to the next sprint: ScrumMaster
Need more information?
By no means, this is neither a complete set of all agile checklists nor I am suggesting that all agile development work can or should be captured into checklists. However, you may think of several recurring activities with some degree of complexity as good candidates for checklists. Some examples: Daily Builds, Compliance and Certification Testing, Customer Trial and Evaluation Testing, Customer Acceptance Testing, Release Packaging, Delivery and Deployment, Customer Support Calls, etc. Even the well-known INVEST criteria can be thought of as a checklist to make sure that stories in a backlog are Independent, Negotiable, Valuable, Estimable and Testable; and the SMART tasks within each story as another checklist for tasks that are Specific, Measurable, Achievable, Relevant and Time-Boxed.
Agile checklists can also be used as an effective mechanism to plan, coordinate, align and synchronize work across a larger number of agile teams on a large-scale agile project, such as a program or a SAFeTM release train of 5 to 10 agile teams working in synchronization on the same cadence, and a set of programs constituting an agile portfolio of several hundred people. Dean Leffingwell’s book on Agile Software Requirementspresents a very comprehensive Release Planning Readiness Checklist in Appendix C. A Wikipedia section on Non-Functional Requirements (NFRs) gives a fairly comprehensive list of NFRs to consider. You may use that list as a checklist to minimize the probability of overlooking or missing one or more NFRs while preparing and grooming your product backlog.
The benefits of agile checklists increase even more when you want a large number of team members on multiple teams of a large-scale agile project to do their coordinated work in a consistent, standard way, and to avoid unnecessary variations among different teams and their members when there is no reason of or benefit from those variations. Thus is the case because larger scale projects create additional complexity due to the need for aligning and synchronizing multiple teams in a program and managing a number of programs into a cohesive portfolio.
An APM tool like VersionOne can make it very easy to templatize these checklists so all items within each checklist can be modeled as tasks and tests in a template; then those tasks and tests can be completed in a consistency way without errors across a large number of people and agile teams. A team can have its own set of checklist templates, and projects and programs can have their own checklist templates, in addition to a standard set of checklist templates that are common for all members, teams, projects and programs in an enterprise. If you are not yet using an APM tool that supports templates, don’t let that stop you from using agile checklists. Try using Excel files on SharePoint or spreadsheet docs on Google Drive for creating and maintaining your checklists. That will get you going quickly.
For additional information on agile checklists, you may find VersionOne agile checklist white paper very informative and imminently actionable.
Have you tried checklists on your agile project? What is your experience?
Are you interested in experimenting with your own set of checklists?
I would love to hear from you either here or by e-mail (Satish.Thatte@VersionOne.com) or on twitter (@smthatte).