Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Prescribed events The Sprint is a container for all other events. Each event in Scrum is a formal opportunity to inspect and adapt Scrum artifacts. These events are specifically designed to enable the transparency required. Failure to operate any events as prescribed results in lost opportunities to inspect and adapt. Events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum.

All Optimally, 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. held at the same time and place to reduce complexity. (Scrum Guide)

Ceremonies

Definition / Purpose

The Sprint

A sprint is a time boxed period during which specific work is completed and made ready for review. TK Sprints are 2 weeks long.
All Sprints should have a Sprint Goal, a unifying theme helping people understand what is to be accomplished in the Sprint. The Sprint Goal often times flows directly from the Product Roadmap/Release Plan. Each Sprint is fixed-scope, with the Team signing up for as much work as they feel they can comfortably complete within the time frame of the sprint.

Sprint Planning

Sprint planning team meeting is a time boxed event that determine which product backlog items will be delivered and how the work will be achievedSprint Planning initiates the Sprint by laying out the work to be performed for the Sprint. This resulting plan is created by the collaborative work of the entire Scrum Team.

The Scrum Team spend time planning the work of the sprint. The team works with the PO to understand in detail the items prioritized by PO at the top of the PBIs to be worked in a sprint from the product backlog and the work required to complete them.

Team commits to PBIs based on team capacity in a sprint. These items , which are moved to the Sprint backlog. To ensure the team remains focused and the work of the sprint is coherent, the team works with the product owner to articulate a sprint goal, a simple statement of the objective of the sprint or the purpose of the next solution increment.

The Daily Scrum (Stand-up)

The daily scrum (stand-up) is a short communication meeting (no more than 15 minutes) in which each team member quickly and transparently covers progress since the last stand-up, planned work before the next meeting, and any impediments that may be blocking his or her progress.

To synchronize the Teams efforts at meeting the Sprint Goal by sharing progress (done work), making commitments (planned work), and asking for help (blockers).

Scrum Guide 2020 - No mention of 3 questions. Team to decide what works best for them.

  • What did I do yesterday to help move the Sprint Goal to completion?

  • What am I going to do today to help move the Sprint Goal to completion?

  • What are your roadblocks (Often shortened to simply “blockers”)?

    purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.

    The Daily Scrum is a 15-minute event for the members of the Scrum Team. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.

    Team can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan. This creates focus and improves self-management.

    The Sprint Review

    The purpose of the Sprint Review is the “show-and-tell” or demonstration event for the team to present the work completed during the sprint. to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

    The Product Owner (PO) checks the work against pre-defined acceptance criteria and either accepts or rejects their work. The stakeholders or clients give feedback to ensure that the delivered increment met the business need.

    The review is an opportunity for stakeholders outside the team to gain confidence in delivery by seeing working solution increments, and to provide feedback to ensure future work remains focused on delivering real business value.

    This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit constructive feedback and foster collaboration.

    Why are sprint reviews important?

  • Partly, because seeing is better than hearing

  • Partly, as a celebration of progress

  • Partly, to receive feedback and adjust

  • Finally, to change/refine plans or features by experiencing the actual working software

    Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

    The Retrospective

    The retrospective is the final team event in the Sprint to determine what went well, what didn’t go well, and how the team can improve in the next sprint.

    This is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to the next Sprint Planning.

    The purpose of the Sprint Retrospective is to:

    Inspect

    purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.

    The Scrum Team inspects how the last Sprint went with regards to

    people

    individuals,

    relationships

    interactions,

    process

    processes,

    and

    tools

  • Identify and order the major items that went well and potential improvements

  • Create a plan for implementing improvements to the way the Scrum Team does its work

  • The retrospective meeting is for the team only. In order to create a safe space for team members to honestly reflect and collaborate on how the team could improve its delivery, and their Definition of Done. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

    The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

    Backlog Refinement

    Not an official event / ceremony of a scrum. It is encouraged for the team to meet regularly and refine backlog items to get ready for upcoming sprints. The Scrum Team decides how and when refinement is done.

    Backlog Refinement provides an opportunity to bring clarity in expectations regarding behavior or functionality to be implemented through the Acceptance Criteria of that PBI.

    This is an ongoing process in which the team collaborate on the details of Product Backlog items. During refinement, items are reviewed and revised. Team is encouraged to size based on what they know at the time of reviewing PBI as it helps with the forecast.

    Why is refinement important?

  • Partly, to clarify and understand PBI

  • Partly, to save time during planning session

  • Finally, to ensure we will be ready for the next sprint

    Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

    Members who will be doing the work are responsible for the sizing. The Product Owner may influence the Developers by helping them understand and select trade-offs.