The first time I heard a story checklist proposed by a team member I was resistant to the idea. Checklists made sense for difficult or risky tasks like deployment, but did we need one for something as mundane as moving a card over on a board? After using checklists for common development activities for many years, I now know they are an easy way to help prevent waste and mistakes.
Checklists help you achieve the goal of standardized work described in the Toyota Production System. This means consistency across time and team members and a mistake-proof process. It is also an explicit agreement between team members about how to perform development tasks: a working agreement. The checklist is a living document that the team can discuss and improve as the project evolves.
Development checklists can help you remember bookkeeping tasks such as moving a card over on a board or marking the status of a story in tracking software. They can also prompt you to check in with other team members. For example, the start of a story is a good opportunity to see whether anyone wants to pair or has information about the story they’ve forgotten to share. For remote teams, these announcements can help the team know who is working on what in real-time.
I’ve found story-start checklists especially useful for ensuring you have everything you need to begin working on a task. What are you trying to achieve? Are the requirements clear? Should you wait for a UI mockup or for a question to be answered? Will the work provide value? Forcing yourself to think through these kinds of questions can prevent waste by revealing that you are not ready to start or that the work is unnecessary.
Story-end checklists can serve as a mini code-review and quality check. Have all of the requirements been met? Is the UI consistent with other areas of the application? Are there performance problems or technical debt that should be addressed? Story end is a perfect time to write up any notes that might be useful for QA or deployment. Your story end checklist can help formalize your team’s definition of “done done” and help catch mistakes before they leave development.
If you decide to give development checklists a try, be sure to get buy-in from the team and keep the checklists visible. On a recent team where we used Trello for story tracking we embedded our start and end checklists right into the cards. This worked well because we were a remote team and our boards were one of our primary information-sharing tools. On an co-located team you could print the checklists and place them at work-stations or on your story board. Having the checklists present in a location that already gets visual traffic makes it easier for the team to adopt them.