Category: Scrum Events

Posted in Scrum Events

Sprint Planning

Posted on by beckycarter

 

“The work to be performed in the Sprint is planned at the Sprint Planning” (1)

Overview

Definition: Sprint Planning is a meeting involving the entire Scrum Team to collaboratively decide what work will be taken up for the Sprint and how the work will be done (2, pg 27)

Length: Maximum of 8 hours for a one-month Sprint

Input: Product Backlog, Definition of Done, Retrospective Improvements, Team Capacity Planning, Impediments, Product Increment

Outcome: Sprint Goal (The What) and Sprint Backlog (The Why)

People: Product Owner, Scrum Master, Development Team

By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. (1)

What can be done this Sprint?

Product Backlog Items

  • The Development Team forecasts the functionality that will be developed during the Sprint for the Product Owner’s objective
  • The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. 

The Sprint Goal

Definition: The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment (1)

  • During Sprint Planning the Scrum Team also crafts a Sprint Goal
  • The Sprint Goal is one coherent function
  • The Sprint Goal means all the Development Team work together rather than on separates objectives
  • The Sprint Backlog items can be negotiated with the Product Owner whilst the Sprint Goal

How will the chosen work get done?

  • The Development team decides how it will deliver the selected Product Backlog Items for the Sprint
  • The Development Team designs the system and the work needed to convert the Product Backlog Items into an Increment
    • Just enough to forecast what it can do in the Sprint
    • Work for the first few days of the Sprint is broken down more
    • Work may be of varying size, or estimated effort
  • The Product Owner helps to clarify and negotiate the selected Product Backlog items
  • The Development Team may also invite people with specific expertise to support them

Sprint Backlog

Product Backlog Items + Plan = Sprint Backlog

Techniques

Sprint Planning Facilitation Technique (3, pg 128)

IMG_20200330_150547

References

  1. The Scrum Guide
  2. Scrum Insights for Practitioners by Hiren Doshi
  3. Fixing Your Scrum by Ryan Ripley and Todd Miller

Explore Other Scrum Events

Sprint Daily Scrum Sprint Review Sprint Retrospective

 

Posted in Scrum Events

Daily Scrum

Posted on by beckycarter

Are we on track to achieve our forecasted Sprint Goal?

Overview

Definition:  […] for the Development Team to synchronise Development Team activities, create a plan for the next twenty-four hours, and ensure everyone in the team is aligned toward the Sprint Goal (3, pg 31)

Length: 15 minutes

Inputs: Sprint Goal, Sprint Backlog, open impediments, (optional) information radiator

Outcome: Update Sprint Goal, updated Sprint Backlog, updated impediments, (optional) updated information radiator. Optimises the chances of achieving the Sprint Goal.

People: Development Team, (optional) Product Owner, (optional) Scrum Master

Timing and Location: Same place, same time every day to set a routine

Structure

The structure is set by the development team.

Common 3 questions (1)

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Daily Scrum Questions (2, pg 152)

  • Is anything stuck?
  • If something is stuck, how can we all work together to get this work unstuck?
  • Who needs help?
  • What’s the most important thing we need to accomplish today?
  • How do we increase the odds that the most important things get to done?

Daily Scrum 1-2-4-All Liberating Structure (2, pg 155)

  1. Devs spend one minute silently answering ‘What opportunities fo you see for making progress on the team’s sprint goal?’
  2. Devs spend 2 minutes in pairs generating ideas and insights on what they thought about in step 1
  3. Each pair joins with another for 4 minutes to develop the ideas further noticing how their ideas compare to each other
  4. Ask the group ‘What stood out during your conversations?’ and have each group share their idea with the team

Fist of Five voting (2, pg 156)

  • Ask the team to express their level of confidence in a statement by voting with the fingers on their hands (1 = Not at all, 3 = need to discuss it more before I agree or disagree, 5 = Totally agree)
  • Example question: ‘How confident are you that we’re on track to meet the sprint goal?’

Techniques

Standing Up (3, pg 33)

  • It is a myth that everyone has to stand up
  • It can be used as a technique to help the meeting not break the 15 minute time-box

Daily Scrum Smells

  • Not a status meeting
  • Not used for detailed discussion and problem resolution

Reference

  1. The Scrum Guide
  2. Fixing Your Scrum by Ryan Ripley and Todd Miller
  3. Scrum Insights for Practitioners by Hiren Doshi

Explore Other Scrum Events

Sprint Sprint Planning Sprint Review Sprint Retrospective
Posted in Scrum Events

Sprint Review

Posted on by beckycarter

“held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed” (1)

Overview

Definition: a formal event to inspect the increment and collaborate on the next things to optimise value

Length: 4 hours for a month long Sprint. For shorter Sprints the event is usually shorter.

Inputs: Product Increment (which must adhere to the Definition of Done), Product Backlog, Impediments that Stakeholders can help resolve

Outcome: Product Increment, Feedback on Product Increment adapted in the Product Backlog, updated impediments

People: Product Owner, Scrum Master, Development Team, Stakeholders (by invitation from the Product Owner)

Sprint Review Contents

The Sprint Review includes the following elements (1)

  • The Product Owner explains what Product Backlog items have been “Done” and what has not been “Done”
  • The Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved
  • The Development Team demonstrates the work that it has “Done” and answers questions about the Increment
  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely target and delivery dates based on progress to date (if needed)
  • The entire group collaborates on what to do next, so that the Sprint Review provides valuable input to subsequent Sprint Planning
  • Review of how the marketplace or potential use of the product might have changed what is the most valuable thing to do next
  • Review of the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of functionality or capability of the product

Sprint Review Agenda (2, pg 37)

  1. Product Owner reviews the planned Sprint Goal and what has been accomplished
  2. The Scrum Team inspects the Product Increment with Stakeholders by discussing the approach they took, reviewing the challenges and their resolutions, and inspecting the Product Increment
  3. The Product Owner discusses the Product Backlog and likely completion date
  4. The Scrum Team and Stakeholders collaborate by determining what to build in the upcoming Sprint

Sprint Review Agenda (3, pg 182)

  • Explanation of the PO’s vision for the product
  • Review of the release plan and budget
  • Description of the Sprint Goal for this sprint
  • Review of the work and the product increment that the team built
  • Assessment of current customer analytics and data
  • Discussion of impediments the team is currently facing
  • Collaborating with stakeholders to refine the Product Backlog
  • Summary of where we’re going next and what we discovered in this event

Techniques

Sprint Review Smells

Sprint Review Smells (2, pg 38)

  • There isn’t anything to show at the Sprint Review so it is cancelled
    • It is a mandatory event so cannot be cancelled
    • Opportunity for inspection and adaption should not be missed
    • Feedback from Stakeholders helps to determine the direction for the next Sprint

References

  1. The Scrum Guide
  2. Scrum Insights for Practitionersby Hiren Doshi
  3. Fixing Your Scrum by Ryan Ripley and Todd Miller

Explore Other Scrum Events

Sprint Sprint Planning Daily Scrum Sprint Retrospective
Posted in Scrum Events

Sprint Retrospective

Posted on by beckycarter

“The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself” (1)

Overview

Definition: The Sprint Retrospective is a formal opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint. (formal opportunity as improvements may happen at any time)

Length: 3 hours for a month long Sprint. For shorter Sprints the event is usually shorter.

Inputs: People, Processes, Practices, Definition of Done

Outcome: Improvements for work processes in the upcoming Sprint, updated Definition of Done

People: Product Owner, Scrum Master, Development Team

Purpose

  1. INSPECT the people, relationships, process, and tools in the last Sprint
  2. IDENTIFY what went well and what could be improved
  3. PLAN for implementing improvements

Scrum Master Role

The Scrum Master…

  • ensures that the event takes place
  • ensures that attendants understand its purpose
  • ensures that the event is positive and productive
  • teaches all to keep the event within the time-box
  • participates as a peer team member from the accountability over the Scrum process
  • encourages the Scrum Team to improve, within the Scrum process framework

Techniques

References

  1. The Scrum Guide

Explore Other Scrum Events

Sprint Sprint Planning Daily Scrum Sprint Review
Posted in Scrum Events

The Sprint

Posted on by beckycarter

“The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.”(1)

Overview

Definition: Sprint is the container event and heart of the Scrum to create potentially releasable product increment (page 25, Scrum Insights for Practitioners)

Length: No more than one month

Outcome: Potentially Releasable Product Increment

People: Product Owner, Scrum Master, Development Team, Stakeholders

Sprint Purpose

  • A Sprint is like a project with a timeline of no more than a one-month horizon to reach a goal (1)
  • First Sprint requires no more than a Product Owner, a team, and enough ideas to potentially complete a full Sprint (2)

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;
  • Quality goals do not decrease; and,
  • Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.

Sprint Length

  • Next sprint starts immediately after the end of the previous
  • Sprint length should be kept constant to maintain a steady rhythm of delivery (2)
  • The time box must be respected and not extended to meet a Sprint Goal
    • Gives the development team the ability to inspect and adapt what is really possible within the Sprint length (2)
  • Scrum recommends the Sprint length of one month or less, but does not stop you having longer Sprints (2)
  • Longer Sprints increase complexity, reduces feedback, and getting valuable feedback from stakeholders

Deciding Sprint Length

Factors to consider when determining Sprint Length (2, pg 27)

  • The frequency of requirement change from market conditions
  • The uncertainty about the technology
  • The frequency the Scrum Team needs feedback from the customers that they are building the ‘right thing’
  • The duration for which the Scrum Team can stay focused on the goal, the team’s maturity, its product knowledge, and interdependencies with external teams

How Long Should a Sprint be? (3, pg 109)

  1. How quickly does the business need to change direction?
  2. How quickly can the DevelopmentTeam create a ‘Done’ Increment?

Sprint Length for Multiple Teams (2, pg 55)

  • Scrum does not require all Scrum teams on the same product to have the same Sprint length
  • In practice, if one team has a four week cadence it does not make sense for another to have a three week cadence as there will be long gaps between a fully integrated increment

Sprint Cancellation

  • Only the Product Owner can cancel a Sprint, but can be influenced by other Scrum Team members or Stakeholders
  • This happens if the Sprint goal becomes obsolete
  • Cancelling a Sprint is expensive as everyone must regroup for Sprint Planning again well as being bad for team morale (1)

What happens when a Sprint is cancelled (1)

  • Any completed and “Done” Product Backlog items are reviewed
    • As the work is potentially releasable the Product Owner may decide to release it
  • All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog

References

  1. The Scrum Guide
  2. Scrum Insights for Practitioners by Hiren Doshi
  3. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl

Explore Other Scrum Artifacts

Product Backlog Increment