The Scrum Checklist
Scrum: Is an agile framework for managing complex adaptive problems using incremental iterations.
This checklist is based on the Scrum guide, it checks that the roles, events, artifacts and rules are correct and working as they should. As long as we humans tend to forget how things work and refuse to follow difficult rules, I decided to write down in a list key points of scrum framework. The list is hosted in a public github repository because receiving contributions are very welcome.
- Everybody understands that Scrum is an incremental and iterative process.
- The process must be visible and transparent to scrum users so everybody shares a common understanding.
- Scrum users inspect scrum artifacts to detect undesirable variances.
- The process or the materials are adapted before the outcomes are unacceptable.
Scrum team members are aligned with these values:
- Commitment, to achieve team goals.
- Courage, to do the right thing and work on tough problems.
- Focus, on the sprint goals.
- Openness, about the challenges with performing the work.
- Respect each other as capable and independent people.
Scrum team is self-organized, to choose how best to accomplish their work.
Scrum team is cross-functional, to have all competencies needed to accomplish the work.
- Maximizes the value of the product with the development team work.
- Product owner decisions are visible.
- Product owner decisions are respected by the entire organization.
- Only product owner manages the product backlog, and:
- Clearly expresses product backlog items.
- Ensures a product backlog visible, transparent and clear for all.
- Ensures development team understands product backlog items.
- Orders product backlog items to best achieve business goals.
- Optimizes value of development team work.
- Shows scrum team what will work on next.
- Work incrementally and iteratively.
- The team is structured and empowered to self-organize their own work.
- No one tells (even scrum master) how to release functionality.
- No one but the product owner tells which requirements to implement.
- The team is cross-functional able to deliver any product increment.
- There are no titles for development team members, regardless of what they do.
- There are no sub-teams, eg: testing, architecture, design,...
- Recognition belongs to the team as a whole.
- The team size is between 3 and 9 members.
Promotes and supports the scrum process.
Enhances the transparency of the scrum artifacts.
Helps everybody to understand the Scrum theory, practices, rules and values.
Is a servant-leader for the scrum team.
Helps to change the interactions with and within the scrum team to maximize the value created.
Helps product owner to:
- Ensure that goals, scope and domain are understood by everyone.
- Find techniques to maintain product backlog effectively.
- Create clear and concise product backlog items.
- Arrange the product backlog to maximize value
- Understand and practice agility.
- Facilitate scrum events as requested or needed.
Helps development team to:
- Coach in self-organization.
- Coach in cross-functionality.
- Create high-value products.
- Remove progress blockers.
- Coach in other organization environments where scrum is not fully adopted or understood.
- Facilitates scrum events as requested or needed.
Helps the organization to:
- Lead and coach in scrum adoption.
- Plan scrum implementations within the organization.
- Work with other scrum masters to increase scrum effectiveness.
All events are time-boxed.
The time must be fixed at the beginning of a sprint, cannot be shortened or lengthened.
Events are transparent, to be inspected, to be adapted.
- The length is from 2 to 4 weeks.
- Has consistent durations.
- New sprints start immediately after the previous concludes.
- A sprint goal is always set.
- Quality goals do not decrease over time.
- Only Product Owner has the authority to cancel a sprint, and only when the sprint goal is obsolete.
- The maximum duration is 8h for a 1 month sprint or equivalent.
- Created by the whole scrum team.
- The Product Owner must set a sprint goal.
- The number of Product Backlog items selected for the sprint backlog, solely depends on the development team.
- The work planned for the first day(s) is decomposed at the end of the meeting.
- The duration is 15 minutes.
- It is held every day.
- It is planned the work for the next 24h.
- Answer the 3 questions, not regarding the items or work but the sprint goal.
- Detailed discussions, adaptations, replannings are outside this meeting.
- The scrum master ensures that the meeting takes place.
- The development team conducts the meeting.
- It lasts 4h maximum for a 1 month sprint or equivalent.
- The product owner reviews what has been "Done" and what has not been "Done".
- What went well, what problems appeared and how were solved is discussed.
- The scrum team reviews what to do next regarding, planning, product, timeline, budget,...
- The product backlog is reviewed.
- It lasts 3h max for a 1 month sprint or equivalent.
- It takes place after the sprint review and before the sprint planning.
- The meeting is positive and productive.
- Inspect people, relationships, process and tools.
- Create a plan to improve how the scrum team works.
- The quality standards and definition of "Done" is adapted in this meeting if needed.
- The output should be a plan of improvement.
- Maximizes transparency of key information.
- The product owner is responsible for its content, availability and ordering.
- The product backlog is never complete. It evolves as the product evolves.
- The product backlog items have description, order, estimation and value.
- Product backlog refinement (add detail, estimations and ordering) takes place iteratively.
- The items on top must be clear and meet the definition of ready.
- Makes visible all the work to meet the sprint goal.
- Must have at least one improvement plan identified in previous sprint retrospective.
- Only the development team manages the sprint backlog.
- It must represent a live picture of the work done and remaining.
- All items must meet the definition of done before are considered finished.
None of the items listed here are based on my experience or intuition, I wanted to create this list because for a long time I was not applying scrum as it should and I was using "common sense" most of the times. If that was your case too, I recommend you this article: We Tried Baseball and It Didn't Work