Download as pdf
Download as pdf
You are on page 1of 1
Agile Checklists Section 8, Lecture 27 While we recognize that there are allot of creative, non-repetitive, varlable work in agile development projects, many wark items, ceremonies, and activities can benefit from systematic, reproducible and standardized tasks test and options that can be captured in customizable checklists prepared and used by empowered agile teams. Checklists allow individual agile team members, agile teams, teams of ‘team(programs), and organized collections of programs(programs), ‘and organized collection of programs(portfolios) to take on complex ‘work and di it right by making it more effective, while reducing avoidable fallure, and in turn, freeing up time and energy for creative challenging and variable work. 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 commen problem in the L.GU, 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 .. itis really relevant to how professionals deal with the increasing, complexity of their responsibilities...It has been years since | 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. CCheekllcts 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-ollowed 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 werk. {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 lst to “get the stupid stuff right” can make a profound difference.” | have been using checklists in my own agile coaching, training, consuking engagements: travel checklist, logistics checklist, preparatory homework checklist, follow-up checklist, etc, Overlooking tone 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 abvious 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. | will now present several examples of checklists applicable at the level of individual agile team members as well as agile teas. Each checklist contains many items (such as tasks, ests, steps, options, questions) with a role assigned to each item (task, test, and step). A checklist may lor may not imply any order for items in it, or it may include a built-in ‘workflow. | recommend you review, customize and try the checklists presented in this blog, and then relentlessly inspect and adapt them, lle, make them work for you with fine tuning and revisions based on your own experience. fa task in a checklist is not applicable in your specifi situation, you are free not to do that task with a reason that you can explain to yourself and to your team members. Ifa 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 alot 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 lt, 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 to complete It and get it accepted by the product owner. If a story requires multiple design and cade 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. ‘naiaandGevelopment | Gully Anurance ech Wing “Leak Spedvihestoinwser fT Mona orpeeati 1 Tek Testenionnent. veie:As0aserok | ord ccentaee ies: etcting: Developer | needed GA tester with att 2 oak Den dana and P-Toak Acepanc Tesco) 12 Tod User dort af fraintontisedondesgnrednr [rattandfraliationbesed | andi fsiztontasedon evtoper revew.aAteser | rev: Techwiter Seat Oeignreew optional fi Tou- Acceptance Testcae 1: Tou User docuret raf ee deopet view by developer: | ree bysftwaredeveper Deoser “Toskcoae devopantend pi Tosk Aceponc Testo) 14 Toi User document Jaf Feakstonbcedon nt eng eee reve QhtesterOntater Tak oaeretew (optional flo Test recwionot | 15 Tou Userdocunant arf eer denioper jpcertiy automated) | reve rosuct ure: eptanceTestandatect | rodutOwnar Defect checklist Defects found, especially outside a sprint such as in production, can be logged withthe 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 53. Task: Fe the defect: Developer 4, Task: Specify the test to verity the defect: QA tester 5. Test Execute the test to very it: Qa tester 6, Task Clase the defect which has been verified as aed: Qa tester 7. Epc Breakdown Checklist This checklist is based on the work done by Richard Lawrence where he recommends 9 patterns that you should try o use to break down an epic (a large story or feature) into smaller user stories. | 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. 1. Workflow steps 2, Business Rule Variations 3. Major Efor 4 Simple/complex 5, Variations in Data 6, Data Entry Methods 7. Deter Performance 4. Operations (eg. CRUD) 19, Break Out a Spike Sprint Planning Readiness Checklist This checklist consists of alist of preparatory tasks that should be completed before starting a Sprint Planning Workshop or Meeting. These tasks should be completed ideally one timebox ahead, ie, 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/responsibltis: Serum Master Task: Draft the key objectives forthe uncoming Sprint: Product mer 3, Task Define and create the project hierarchy ingle Project management (APM) tool, and make sure the members of the Ale tear have the right role assigned on the project: Scrum Master working with APM tool administrator 4, Task Create the Sprint backlog APM too! Product Owner working ith Business analysts Epics, stores (preferably satisfying the INVEST criteria, Defects, Spkes Maintenance work, porting work, certification ork, Regression testing, System testing, Performance testing, ec. Task: Explain and clay the spin backlog to team members for the upcoming, sprint by conducting one or more sessions ane tmebox ahead, le, prin work ‘done ina pipeine mode 6, Task: Calculate agile capacy fr the team and each team member forthe ‘Upcoming sprint Scrum Master working with each team member Task: Prepare the preliminary rank oder of backlog tems based on business valve (Optional Product Owner Task: Make sure alr environments are in place: Serum Master working wath Staff: Development, QA build machine, continuous integration server, software licenses, est data, ary special hardware needed ‘9, Task: Review the Sprint Ready checklist (see below) and take necessary actions 0 the Age tear wl be 100% ready to stat the sprint. as soon as the Sprint Planning Workshop is aver: Scrum Maser 10. Task Complete al logistical arrangements for Sprint Panning Workshop (venue decided, attendees identified and invited, workshop material arranged, fod ordered etc Scrum Master Sprint Planning Workshop Checklist ‘The checklist shown in Table 2 consists of many 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 wellelled teams, this planning time should come down to 3 day for two-week sprint planning to 1-day for four-week sprint planning, Table 2: Sprint Planning Workshop Checklist Tr: Preset oneview Spintboy objectives | Teter nd ine dependences Gntwasaheneypepredprartoworsng: | monsters pnt cog Teams. ‘Dr reset andthe tear andinguial | Ti fioa gamatchot anion wah apy Cnecty-dtltvenpremederortoworshos | [ees inary forcapect tnd oming ":tesew onli bc ctor | TO Loeinong Ditibae wononderey ‘runing acKogwarpepredore timation | acrastearimemters Shae, ea Teioe graneloresinadonofCusBstoies | TH: into tam menber the record Innumter fies nade primary fr | keeping tat wile Pll frst cect bse planing) Tears 2he respecte: Surat, Tear 0.25 TS onypo etnatin Tears Shr TR Ger end ortarting eat Seramstr, team 25 PiSe Set Resa Chectatbloe) conspiring Wor, ondcorle the osm : : Tr Comerlrgestoriestacpesangrltthem | 6 Gt pit an eveweaby maneger ond bya Teamt We Saker, approve thn Poot nara rant pari ith sore Sprint Ready Checklist ‘This checklist consists ofa set of tasks that must be completed before a sprint should start and ean run smoothly. If there is major incompletion of any of these tasks, it would be premature and risky to starta sprint, as it will experience obstacles, hick-ups, delays and impediments. 1. Tas: Sprint objectives are wel defined Product Owner 2. Task Fullinventory of al work items is avaiable, anal tasks and tests in stories ofthe sprint backlog are properly defined and have proper estimates: Product Owner, Scrum Master “Task: Acceptance tess for each User story are well defines: Product Owner, QA tester 4. Task I Agile team memibers are identified, thelr roles defined and necessary training completed or plans made: Scrum Master ask Indvidua an total capacities and Individual an total estimated eons match (for cepaciy:based planning: Scrum Master 6, Task Various standards (coding, testing, documentation, bull, user interface, compliance, et for your project are defined and easly valabe: Scrum Master, Team Leads Task Al environments, infrastructure and test sets requlred forthe Sprint are avalable: Serum Master and IT staff Task: Works alstributed evenly across all members of Agile team (oad balancing done}: Scrum Master ‘9, Task ll stories inthe Sprint are linearly rank ordered: Product Owner with Team 10. Task Sprint Done Checklists well defined: Product Owner with Team, 11. Tas: Any remaining small tasks that must be completed to reach 100% Ready state are documented (and are not showstopper Scrum Master Daily Scrum Checklist ‘This checklist consists ofa set of tasks for each individual member and the Scrum Master. See specific details in my blog on Dally Scrum. 1. Task: Ensure that the Dally Scrum room venue and timings the same for every ay na sprint: Scrum Master 2. Task: Invite each member ofthe Agile team for Daly Scrum on astanlng basis for every day throughout the sprint duration: Scrum Master Task: Prepare forthe Dally Scrum meeting head of the actual meeting: Each team member {2 Report on the status of yesterdays tasks agains the plan for yesterday b Present the plan for today tasks «Present what do need from any other team members to do my work 4. Present any Impediments onthe harizan that could lock my wor. 4. Task Present key information radiators from APM too, such as burn-down and bourmup charts, Cumulative Fiow diagram, Impediments being worked on: Serum Master 5. Task: Capture any risks, sues, and decisions coming aut of Daly Serum: Scrum Master {Sprint Done Checklist This checklist consists af set of tasks that must be completed before a sprint can be declared successfully Done’. This It ensures ‘unambiguous completion ofa sprint. 6, Task Acceptance testing completed QA testers 7. Task: Defect xing work completed: Developers 8, Task Fixed defects are verified and closed by QA members ofthe agile team: Ontesters 9, Task The lst of defects tobe pushed out to the next sprints nalzed: Product ‘Owner, Scrum Master, Team 10, Task: Altechncal documentation is completes: Technical leads 11. Task ll user documentation is completed and is ready tobe released to sprint Users: Tech writer 12. Task: Sprint release can be delivered to interested customers and users ready torreceive it: Scrum Master 13. Task ll data in APM tool's up-to-date and consistent with the completion (Gone) state ofthis sprint: Scrum Master and Team 14. Task: Sprint delivery has met the Sprint objectives: Product Owner 15. Tas Sprint relence is accepted by the Product nner: Product omer 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. 1. Task Determine upto 3 top things that worked well and the team wants to contioue: Team 2. Task: Determine upto 3top things that were most problema, and the tear wants te discontinue or change: Team 2. Task Determine upto top up ta 3 impediments and their rot causes: Serum Master 4. Task: Capture and prasent key stats, suchas initial capaityof the team, planned ve actual velocity, scope change, Mast ofthese are reports generated bby APM took Serum Master 5. Task Develop 3t 5 specication items as part ofthe Specific, Measurable, Achievabl, Realist, Time-bound (SMART) action plan toimprove the agile process: Team 6. Task: Convert the SMART action items int Stories in APM tool, and assign them to the next sprint: Scrum Master Need more information? By no means, this is neither a complete set of all agile checklists nor! 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: Dally Bullds, Compliance and Certification Testing, Customer Trial and Evaluation Testing, Customer ‘Acceptance Testing, Release Packaging, Delivery and Deployment, Customer Support Calls, ete. Even the well-known INVEST criteria ean bbe 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 5to 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 Requirements presents a very comprehensive Release Planning Readiness Checklist in Appendix C, A Wikipedia section on Non- Functional Requirements (NFR) gives a 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 many 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 fram 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 many programs into a cohesive portfolio, ‘Aglle project management software 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 many people and agile teams. A team can have its own set of checklist ‘templates, and projects and programs can have thelr 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. Ifyou 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. Have you tried checklists on your agile project? What Is your experience? Post to this class and let us know your experience

You might also like