I always thought the checklist mindset was more of a high school assignment submission. Do they make a person mindless? Are they useful? Are they only good for pilots?
Checklists start off in my life as to-do lists. To-do lists always helped me to do better. It helps in memorizing some of the key tasks for the day. Checklists are next level to To-Do Lists.
They help in avoiding sudden errors and mistakes. For sprint planning and execution, should we have a checklist? Will it help?
![Checklist]()
While planning for the sprint, you will want to cover most of the critical things like product backlog, timeline, priorities, and estimates. The other important one is the engineer’s commitment to the sprint. The First of the Five method helps ensure consensus over the estimates, priorities, and timelines for different user stories. What are the goals of the sprint? This is another important question. Many times, ensuring the sprint goal is met vs sprint backlog analysis is better. Ensure that you deliver the committed user stories as per the sprint goals.
![Plan]()
Some people think the consensus is a hurdle in the scrum. The objections raised need to be right and they need to have better solutions. Timeboxing a user story is more important than gaining consensus for estimates. Gaining trust and making the engineers accountable is a better approach. Focusing on ownership in the team is better than worrying about the imbalance of mindsets in the team. I thought having software to brainstorm was another important one on the checklist.
Some of the questions that come to mind during sprint planning are,
- What is the value of a sprint and release?
- Are you over-committing or under-committing?
- Are all team members committed to the sprint?
- Are there any planned vacations or leaves?
- What are the high-priority items in the product backlog?
- How many meetings are planned during the sprint?
- What are the impediments that keep coming based on the retros?
Coming back to the checklist, do we have a paper-based checklist or a document that you review during the sprint review meeting? Normally when we whiteboard the product backlog items (PBIs), some of these questions come in to create a sprint plan. Conversations happen during the session, which turns into estimates, commitments, and priorities. Are there any defects from the previous sprint moving into the current sprint? This might change the sprint planning if the sprint goals have a goal related to targeting low-priority defects from the previous sprint. Agile methods provide a framework to pick work items and prioritize them based on their goals.