Decide whether the Sprint is a timeboxed event#19
Many people have doubts as to how to understand the word “timebox”. After a heated debate on LinkedIn I spoke with Jeff Sutherland and he confirmed that the Sprint is a timeboxed event.
This can be indirectly deduced from the statement:
“The Scrum Master serves the Scrum Team in several ways, including (…) Ensuring that all Scrum events take place and are positive, productive, and kept within the timebox.” - Scrum Guide 2020
The current definition of the Sprint does not mention this:
“They are fixed length events of one month or less to create consistency. A new Sprint starts immediately after the conclusion of the previous Sprint.” - Scrum Guide 2020
But it was the case in Scrum Guide 2017:
“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. Sprints have consistent durations throughout a development effort.”
I see two options:
a) Make it clear again
b) Agree that Sprint is the only event that is not timeboxed
As the Sprint is a scrum event, and all events are time boxed, how is it then deduced that the sprint isn’t time boxed? It is implied.
It is not clear even for some professional Scrum trainers from Scrum Alliance: https://tinyurl.com/4s4u96h3
Is the Sprint time boxed though? Or is it a fixed length event? The SG states this. Timeboxed means there’s a maximum length and you can finish earlier when done. But the Sprintbis fixed length.
For the Sprint Planning, Sprint Review and Sprint Retrospective, it is explicitly stated that these are timeboxed, they have a maximum duration and can be concluded sooner.
The Daily Scrum and the Sprint itself have have a fixed length and should not be concluded sooner.
The Scrum Guide also contains this:
“Optimally, all events are held at the same time and place to reduce complexity.”
The Sprint having a variable length would go against this.
What is the difference between fixed length and timeboxed?
Timebox = maximum time but can end sooner.
Fixed length = wathever happens the minimum and maximum time is the same.
A daily scrum can take up to 15minutes maximum. A sprint has a fixed length and takes (fior example) always 2 calendar weeks.
Agree?
Sprint lengths however may not vary from one sprint to the next.
Scrum provides an active risk control mechanism using timeboxes. The intention is not to exhibit micromanagement of time, insted it is there to serve as a forced inspection point regardless of progress. It is there to raise transparency of the effectiveness event. Many teams mechanically run the event, but fail to inspect the event and question whether or not that event is effective and how it can be improved.
The underlying misunderstanding of this post is Mechanical execution of Scrum versus the emperical inspection point.
As professionals, we want to have regular inspectins so we can openly talk about things that are not going as anticipated. This allows empowered teams to adapt and fix it.
If one does not have these inspection points, one looses the ability to be really pragmatic. Issues will be masked or hidden.
One should stop seing timeboxes as maximum meeting lengths, and instead see the nature of having heart-to-heart conversations at regular intervals on “Is this working”. Reveal good, bad or ugly and then inspect and adapt.
We need to stop the misunderstandings of Mechancial use of timeboxes and get to the essence of the “GUIDE”, that is empericism.
@Martin A. Schuurman the Daily Scrum is also fixed length. So 15 minutes, not ‘up to’.
@Sjoerd Nijland you are, of course, right. I think this need to be changed in the next version of the scrum.guide.
@Brett I do not agree. A timebox is there to prevent endless discussions. No one will stop you from interaction besides, for instance, the daily scrum. But the daily scrum is #opinion most effective if kept within the timebox. The SG however says it MUST take 15 minutes but that seems quite funny.
@Pawel Huryn good point. I think both a) and b) do apply
Interesting how much we can discuss a simple term ;)
For me timebox is more than a maximum length. The goal of timeboxing is to do the best you can before timebox expires without doing it perfectly, which in complex environment is likely to be wastefull.
For the Sprint Planning - we need to make the best possible plan for the upcoming Sprint (initiate the Sprint Backlog). It won’t be perfect. But that’s ok - it is a living artifact. Developers will inspect the progress toward the Sprint Goal and adapt the Sprint Backlog as necessary every working day of the Sprint.
For the Sprint - we need to focus on a Sprint Goal and to deliver valuable, usefull Increment. It won’t be perfect. But that’s ok - it will allow us to inspect the progress toward the Product Goal and determine future adaptations.
In my opinion, fixed length is a special type of a timebox, but only when there is a goal. For example, 8 hours of sitting in the office is not timeboxed, if there is nothing that needs to be done by the end of a day e.g. when it’s just sitting and waiting for a call.
For the Sprint, it’s important to create a consistency. I get it. That’s why it’s a fixed-length timebox.
But for the Daily Scrum, I see no argument for having a fixed-length event, although indeed, the Scrum Guide says “15 minute event”. In my opinion, this should be changed.
@Martin A. Schuurman . The Scrum guide currently says “Scrum combines four formal events for inspection and adaptation within a containing event, the Sprint. These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.”
The point of the events are to create opportunities for insepection. They are not there to micro-manage people’s time.
Frankly, a conversation is going to take as long as it needs regardless of timeboxes. e.g. If you cannot complete your planning in your sprint planning, the remainder planning will still need to be done at some point. Nothing is going to make it magically complete itself. What the timebox is doing, is crating an opporunity to stop and ask “So we did not finish planning, how can we do this better?”. “What are we going to do with the unplanned work”
Please don’t be a Scrum Police and micro-manage people’s time and whip people because they have not managed time correctly. Instead use the timeboxes to raise transparency of what is happening, and allow them to assess if it is working or not.
Its not ‘either/or’. They are complementary.
- You do a Sprint
- To achieve a Goal (Deliver value)
- Within a timebox
- Which supports regular inspection & adaptation (Max 1 month)
- All of which ensures decisions are being made based on up to date real-world data (Empiricism).
If you achieve the Goal early within the timebox, you identify what you can learn, when you can learn it, and what you assume is best to do next based off that learning.
If you learn that you now have to wait 3 days for the Sprint review, then identify something else of value that you might get done in 3 days and do it. Maybe reduce the length of your next Sprint if you dont need it as long as this one was.
If you learn that your stakeholders are very engaged and they are happy to give feedback sooner, then reschedule the Sprint review for tomorrow, so you dont delay the learning and next sprints attempt to maximise value. Or go ahead and release then discuss it in the sprint review as planned.
Scrum is really simple, every time you dont know what to do, just ask “Will this decision help me learn how to maximise value faster?” (Empiricism). If the answer is yes, do it. If the answer is no, dont do it.
The daily scrum should not have a ‘fixed length’ instead of a timebox (Nor the Sprint). If you cover everything needed in 12 minutes but stay there longer, thats 3 minutes delay to learning how to maximise the delivery of value. Thats 12 hours delay per year by x number of teams.
P.S. The sprint is timeboxed because if it goes on for too long you lose empiricism. Its not fixed because if it goes on longer than necessary, you reduce your empiricism.