I suggest you ...

Don't prescribe exactly the exact length of sprint review & retro

In the "Sprint Review" section it says: "This is a four-hour time-boxed meeting for one-month Sprints."
Change to "This is at *at most* a four-hour time boxed meeting for one-month Sprints".

Same with Sprint Retrospective. Change to "at most a three-hour time-boxed meeting".

Rationale: No need to prescribe an exact length. A max length makes more sense. Shorter is often better. Plus, this is consistent with how sprint planning meeting is described ("time-boxed to a maximum of eight hours for a one-month Sprint").

141 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Henrik KnibergHenrik Kniberg shared this idea  ·   ·  Admin →

    15 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Anonymous commented  · 

        I have worked on different projects which employed 2 week, 3 week and 4 week sprints. None of them needed a 4 hour long review, EVER! While, my "2-week-sprint-project" had 1 to 3 hour review meetings on need basis; my other "3-week-sprint-project" needed mostly less than an hour to conclude review meetings. All these made sense to me!

        My opinion:
        You do not need to prescribe duration for sprint reviews, retros, plannings.It is totally dependent on the kind of project we do, the kind of shippable items we bring to the table for demonstration during the review. It all depends on how quickly the Product Owner can assess the 'DONE' items and approve the stories!

      • Jeff Sutherland & Gabby BenefieldJeff Sutherland & Gabby Benefield commented  · 

        I think we have handled this in the guide - "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."

      • Tom PoloTom Polo commented  · 

        Scrum ceremonies are not meetings that should have any time, it must be time-boxed, not more and not less than the defined. This is an example of things that should be not even discussed.

      • Alan LarimerAlan Larimer commented  · 

        It's always frustrating when people don't understand time-boxes despite its clear explanation, "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."

        The minimum time idea made me think for a moment, but how does that fit in reducing waste or maximizing the work not done?

      • Anonymous commented  · 

        This change is not necessary, because a time-box implies that a maximal time is stated.

      • Anonymous commented  · 

        Trust teams. Once they get it, they take just the right amount of time. Initial guidance, max limit may be helpful.

      • Ola BergOla Berg commented  · 

        Since so many misinterprets "time-box" that should be a reason to change the wording.

      • Joseph HurtadoJoseph Hurtado commented  · 

        Henrik, agreed 100% And an indea Scrum can learn from Kanban and Lean Thinking. Within the Kanban Ace framework we call this bespoke cadence. A cadence that matches the needs of the moment, the business and the teram.

      • Eric RapinEric Rapin commented  · 

        I agree with Adam's comment, especially with regards to retrospectives. I've heard Diana Larsen assert that good group decision-making needs at least 75-90 minutes to occur. In my experience, teams that rush through this ceremony often don't focus on improvement much and quite frequently abandon the ceremony as a waste of time. Perhaps a recommended minimum for retros would be a good idea.

      • Naveen NanjundappaNaveen Nanjundappa commented  · 

        Time boxed means - maximum of .. or no longer than as Fredrik mentioned.
        I wouldn't consider it for any edition.. if required we can explicitly mention "maximum of"

        There is nothing in scrum that says, we can't do it in shorter time and be effective and efficient. So I find it just good. May be it's just how we interpret the statement/words

      • gene gendelgene gendel commented  · 

        could be situational. setting higher boundaries is more important then lower boundaries. voted

      • Fredrik WendtFredrik Wendt commented  · 

        But it doesn't prescribe an exact length: "time-boxed" already means "no longer than".

      • Jens AbrahamssonJens Abrahamsson commented  · 

        Your suggestion makes perfect sense. However, there is of course the risk that no lower time limit of the review and retrospective might make some people more inclined to hurry through retros and reviews, which could make these events wasteful.

      • Adam YuretAdam Yuret commented  · 

        Shorter is not often better... I agree that providing heuristics is better than mandates which is one way to interpret this writing but in my experience teams give FAR too little time to retrospectives especially. There's already too much focus on reducing time spent doing important things like talking to each other, setting maximums is just as potentially destructive as setting a prescribed length. I've yet to encounter a team doing Scrum who's not trying to squeeze a retro into 30 minutes during which nothing actually gets examined effectively much less an experiment designed for the subsequent iteration.

        Also, I think anyone who takes some guide as gospel and mandate is missing the plot entirely of a 'framework' it's a guideline not a rigid mandate. Thirdly, almost nobody I've run into has read the guide itself, including CSMs and professional coaches. Everyone is shocked when I tell them there are no story points of poker in the guide, because most of them have never read it. Even fewer people have read Nonaka's paper that preceded this guide so I'm not sure petitioning to change it would make a significant meaningful impact on the ways in which Scrum is practiced today. Don't get me wrong, there's plenty I'd like to change in the guide, I'm just not sure it's necessarily going to make a difference to how people have chosen to interpret Scrum given how infrequently it seems to be read by those professing to be doing, implementing or coaching it.

      Feedback and Knowledge Base