This is my attempt at short actionable checklists to guide key moments in software process.

I previously wrote a software checklist based on increments of time. I was reading more about checklists and noticed many are based on key events in some process. I later learned these key moments are called pause points.

Here’s my attempt to identify key process moments (pause points) for software, and what is most important to verify at that juncture. I also aimed to keep the list very short.

The Checklist

Commiting Code

  • Is the code well covered with automated tests?
  • Is the commit only a single focused change? (e.g. a rename, a small refactor, a preparatory refactor, a small behavior change and it’s tests)
  • Is the commit message clear and descriptive of context for the change?
  • Could I pull request / integrate my work?
  • Have I pushed my changes?

Integration

  • Does the code pass all automated checks?
  • Does the work satisfy acceptance criteria?
  • Is the completed work small, cohesive, and production stable?
  • Does the pull request include all context a reviewer needs to understand the change?
  • Have all required reviewers approved?

Work planning

  • Does this work have clear acceptance criteria?
  • Is the scope of this work estimated and less than 1 week?
  • Are upstream dependencies completed?
  • Does the developer have everthing needed to execute the task (information, experience, support)?

Deployment

  • Is the deployment automated?
  • Do we have a recovery strategy?
  • Do we have measures to detect change failure?
  • Have any migrations been validated and proven backwards-compatible?
  • Has this code passed robust automated checks, review, acceptance criteria, and been merged into trunk/main?

Thoughts

I was impressed how easily this checklist came together and how much it covers.

There is certainly much I think about that is not covered by this checklist. However, I think I would be comfortable supporting most code that can pass this checklist. It promotes small units of work, testing, review, and safe deployment.

This list is also pretty low-controversy. Almost every item is generally accepted good practice. Many are well proven indicators of team performance.

I might potentially add documentation and self-documentation in various places.

I would also consider additional checklists for team process events like stand-up and retrospective. However, those checklists would be oriented for the engineering manager or project manager.