Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened. The remaining events may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process.

Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.

Scrum Events	When	Who	What	Why	How	Tools

Scrum Events	When	Who	What	Why	How	Tools
Sprint Planning	Start of each Sprint	Product Owner Scrum Master Dev Team	Timeboxed to 2-4 hours at start of each sprint Team agrees to complete a set of backlog items Define sprint backlog based on team’s velocity/capacity & Sprint length Team decides how chosen work will get done	Define what can be done this Sprint How will the chosen work get done Establishes the Sprint goals	Review previous Sprint work Capacity Planning/Vacations Release Planning Considerations Product Owner reviews sprint stories Team creates and breakdown tasks Validate team assigned work to capacity Set Sprint goal/ Definition of Done Team commits to sprint (Fist of Five) Start Sprint	Sprint Backlog
Daily Scrum	Daily same time	Product Owner Scrum Master Dev Team	Timeboxed to 15 minutes daily Team meets daily once Sprint starts Dev Team meets to plan their day	Inspect and adapt progress towards Sprint Goal for next 24 hour Highlight and remove impediments Dev Team plans their work	Team member answers three question: What did I do yesterday? What will I do today? Any impediment that prevents me to proceed?	Sprint Backlog
Backlog Refinement	Once Weekly	Product Owner Scrum Master Dev Team	Timeboxed to 1-2 hours weekly Prepare work for upcoming Sprints Assign a relative story point value Identify and remove dependencies Define acceptance criteria Meets INVEST criteria	Ensure all sprint stories meet the team’s definition of ready. Part of Sprint Planning but broken into separate meeting to identify dependencies, plan/estimate upcoming work and remove impediments.	Product Owner to Prioritize Product Backlog Team to discuss each story and refine backlog Agree on user story Acceptance Criteria Llink assets to stories (designs, content, API, etc.) Estimate stories, add story point value in JIRA Flag stories if not ready with comment to action	Planning Poker Product Backlog
The Sprint	2 Weeks	Development Team	Timeboxed to 2 weeks Team works on assigned sprint activities	Empowers team to work on stories Create potential releasable product	Team delivers working increment of product feature/function Team collaborates collectively to complete tasks/stories Team to update active Sprint Board daily	Sprint Board Sprint Backlog
Sprint Review	End of each Sprint	Product Owner Scrum Master Dev Team Stakeholders	Timeboxed to 1 hour at end of Sprint Meeting held after Sprint ends Entire Scrum team should participate Open to anyone interested in reviewing the sprint’s accomplishments.	Review and demonstrate the user stories that the development team completed during the sprint. Stakeholders get a chance to see product progress and provide feedback	Demonstrate completed user stories to team, stakeholders and business owners. Discuss Sprint Goal \|Impediments PO to document any feedback for Backlog Product Release overview and any changes	Sprint Report Product Demo
Sprint Retrospective	End of each Sprint	Product Owner Scrum Master Dev Team	Timeboxed to 1 hour at end of Sprint Team meets after Sprint ends Members working on Sprint need to attend	The team reflects on what happened in the iteration and identifies actions for improvement going forward. Identify if any changes to Definition of Done.	Opportunity to inspect and adapt the processes: What went well What can be improved What to change	Retro Board Retro Games Confluence