Posted in Scrum Events

Sprint Retrospective Real Examples

Pixar (1)

Notes Day is a day in which employees tell management how to make Pixar better. No visitors allowed and everyone must attend.

‘we have a problem and we believe the only people who know what to do about it are you’ 

page 282


  • People submit discussion topics in advance 
    • Go through them (pick ones which you can imagine 20 people talking about for an hour) (1, page 283)
    • Schedule sessions and let people sign up for it themselves  (1, page 284)
  • Start the day off by a intro speech
    • John Lassiter gave an example of being thankful for the feedback that he personally received and reminder how important honesty is and not to feel attacked personally
  • First session was within departments to warm everyone up being candid with people that they worked with regularly before having to do it around strangers
  • Subsequent discussion sessions scheduled that people submitted and signed themselves up to in advance of the day
    • Executives and directors did not join these sessions (to allow safety) and addressed their own issues together separately
    • Each session has exit forms to be filled in to capture the discussions
    • The exit form included the final line of ‘who should pitch this proposal (i.e. a volunteer) (1, page 286) 
  • Social event afterwards
  • Afterwards volunteers who signed up to pitch the proposal presented them to the execs who immediately began implementing the ones that made sense, or earmarked to do at a later stage when it was more logical (1, page 292)

Reasons for success (1, page 293)

  • Clear and focused goal
    • They used the fact that it was costing too much and something needed to be done to hit specific financial goal
  • Championed by the highest levels of the company 
  • It was led from within, no outside consultancy running it
    • The commitment was contagious 


  1. Creativity Inc. by Ed Catmull

Explore more


Agile Games
Posted in Scrum Events

Sprint Review Real Examples

Pixar (3)

Pixar use regular meetings every few months called Braintrust Meetings to inspect progress made on a film, talk through what works and what doesn’t, and how to adapt the film to improve (i.e. similar to a Sprint Review).

‘put smart passionate people in a room together, charge them with identifying and solving problems, and encourage them to be candid with one another’

page 86-7

Structure (1, page 94)

  • Film screening 
  • Lunch together in a conference room (to gather thoughts) 
  • Director will give a summary of where they think they are
  • Feedback begins

Feedback (page 93)

  • Braintrust notes, then, are intended to bring the true causes of problems to the surface – not to demand a specific remedy (page 93)
  • The director (as mirrors the PO role) is able to change whatever he/she wants from the feedback
  • Feedback is given as constructive criticism (page 103) 
    • “The writing in this scene isn’t good enough” (just criticism) 
    • “Don’t you want people to walk out of the theater and be quoting those lines?” (more of a challenge and shows you want the same things) 


  1. Creativity Inc. by Ed Catmull

Explore more


Agile games
Posted in Scrum Events

Sprint Planning

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


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


Sprint Planning Facilitation Technique (3, page 128)



  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

SprintDaily ScrumSprint ReviewSprint Retrospective
Posted in Scrum Events

Daily Scrum

Are we on track to achieve our forecasted Sprint Goal?


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


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, page 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, page 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, page 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?’


Standing Up (3, page 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


  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

SprintSprint PlanningSprint ReviewSprint Retrospective
Posted in Scrum Events

Sprint Review

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


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, page 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, page 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


Sprint Review Smells

Sprint Review Smells (2, page 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

See also


  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

SprintSprint PlanningDaily ScrumSprint Retrospective
Posted in Scrum Events

Sprint Retrospective

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


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


  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



  1. The Scrum Guide

Explore Other Scrum Events

SprintSprint PlanningDaily ScrumSprint Review
Posted in Scrum Events

The Sprint

“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)


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

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, page 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, page 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, page 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


  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 BacklogIncrement