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").
Resolved in 2017 release by defining a Time Box. Reality is that it was never prescribed as length because a Time Box is a maximum, but now it is clearer.
20 commentsComments are closed
Mike Jones (MikeJonesTechno) commented
@jeff-sutherland Please could we mark this one as completed now?
The problem is that time-box is not used consistently. People latch onto the Sprint as the main example of an event in Scrum and this is described as: "The heart of Scrum is a Sprint, a time-box of one month or less". (p8)
However it is NOT a time-box! It is a fixed-time-length event. The "or less" implies that it is a time-box, but it isn't.
If your Daily Scrum lasts 5 minutes, great get on with the development work. If your Sprint Review lasts an hour and a half, great. If your two-week Sprint is planned to finish in a week and a half - find some more Product Backlog Items which you can do to meet the Sprint Goal to extend it to two weeks.
If you remove the word Time-box from the Sprint, then I think that everyone would understand that the other event time-boxes are more elastic.
Perhaps the word "box" doesn't help. A box has fixed dimensions. Perhaps there ought to be a more squashy word. Perhaps time-balloon? You can blow up a balloon as much or as little as you like, but there is a minimim size it must be to be a balloon rather than a bit of rubber, and a maximum size it can be before it bursts and becomes useless.
This was our original intent. Wording will be changed.
Definitely should be maximum length timebox.
Melvin Perez-Cedano commented
I think this is addressed on page 7: "The remaining events [other than the Sprint itself] may end whenever the purpose of the event is achieved, ensuring an appropriate amount of time is spent without allowing waste in the process."
However, I prefer referring to events duration in terms of the Sprint length (e.g., for Sprint Review: up to one hour per week of duration of the Sprint)
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!
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!
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 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 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?
This change is not necessary, because a time-box implies that a maximal time is stated.
Trust teams. Once they get it, they take just the right amount of time. Initial guidance, max limit may be helpful.
Ola Berg commented
Since so many misinterprets "time-box" that should be a reason to change the wording.
Joseph 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 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 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 gendel commented
could be situational. setting higher boundaries is more important then lower boundaries. voted
Fredrik Wendt commented
But it doesn't prescribe an exact length: "time-boxed" already means "no longer than".
Martien van Steenbergen commented
Does it need to be a hard or soft limit?
Jens 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 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.