Some guidelines from The Checklist Manifesto.
You must define a clear pause point at which the checklist is supposed to be used (unless the moment is obvious, like when a warning light goes on or an engine fails).
You must decide whether you want a DO-CONFIRM checklist or a READ-DO checklist. With a DO-CONFIRM checklist, he said, team members perform their jobs from memory and experience, often separately. But then they stop. They pause to run the checklist and confirm that everything that was supposed to be done was done. With a READ-DO checklist, on the other hand, people carry out the tasks as they check them off.
The checklist cannot be lengthy. A rule of thumb some use is to keep it to between five and nine items, which is the limit of working memory.
But after about sixty to ninety seconds at a given pause point, the checklist often becomes a distraction from other things. People start "shortcutting." Steps get missed. So you want to keep the list short by focusing on what he called "the killer items"--the steps that are most dangerous to skip and sometimes overlooked nonetheless.
All of these points could just as easily apply to something as non life-critical as software development. Developers are more apt to skip any oversight unless it is absolutely minimal drag, and are just as easily prone to solitary labour vs team coordination.