What does timeboxing mean? When can a sprint be cancelled and by whom?
Welcome to part 58 in our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.
This is an interesting interview question because neither of the questions relate to one another, they are two separate questions.
What does timeboxing mean?
Let’s start with the first question. What does timeboxing mean?
A timebox is a limited period of time to get work done.
Simple. You allocate X amount of time for an event, such as sprint planning, and you ensure that everybody is focused on achieving the outcomes necessary for the event.
In some cases, you and the team will be designing those time frames in alignment with what works best for you, whilst at other times you’ll be working to industry standard timeboxes as recommended in the scrum guide.
The value of the time box is that everyone is focused on an outcome or objective, knowing that there is limited time available to achieve that. There are no extensions. There are no delays. It is designed to keep people accountable for delivering an outcome within a pre-agreed period.
Sprint
A sprint is a great example of a time box.
The team agree on a sprint length of two weeks, for example, and within those two weeks the team are committed to delivering a working increment (software or product or feature) for the customer, and to achieving the sprint goal that guides the sprint.
Boom.
No kicking it out another week because we weren’t done yet. No delays because people want some extra time in pointless meetings. Just a short, sharp burst of production with a guaranteed outcome for the customer to review in the Sprint Review.
Sprint Planning
Sprint planning is another great example of a time box.
The scrum guide recommends a maximum of four (4) hours of sprint planning for a two (2) week sprint.
If we don’t have a time box in place, and we have meeting after meeting after follow-up meeting, we will seldom get anything of value done. We need to commit to a timebox that enables us to focus on planning effectively but doesn’t allow enough time for people to stray off-piste.
- What are we doing?
- Why does it matter?
- How are we doing it?
- What do we anticipate might get in the way of achieving our objective?
- Is this the most valuable work to be delivering in the sprint?
- What is our primary commitment? What is the sprint goal we commit to in this sprint?
And so forth.
Short, sharp, and effective.
Sure, you may not get it right the first time, but you can take what you have learned through the process and become more effective with planning in the next sprint planning session. Great, make a note of it, and practise until you master this element of scrum.
The time box ensures that you stay focused, deliver against what truly matters to the team, and get work done.
When can a sprint be cancelled.
It is very rare to see a sprint be cancelled in scrum, mainly because they vary between one and four weeks in length. It is a short, sharp period of production and it is rare that something happens, that is so significant, which warrants us cancelling the sprint.
So, why would it be cancelled?
The process would be to identify who the sprint is for, in most cases it is for the customer, and so we might identify that an item is no longer needed or that the customer need to pivot to something completely different due to disruption or compliance issues.
Maybe a mistake happened in the customer environment and the sprint goal is no longer viable or achievable, and as such, the team make the decision to cancel the sprint.
Persisting with the work or pursuing the sprint goal simply doesn’t matter anymore.
Who could cancel the sprint?
The developers are the ones building the product, but the product owner is the person who is ultimately responsible for what is built and when it is shipped to the customer.
The buck stops with them.
So, you would find that decisions are rarely made outside of the team environment, independently, but if it boiled down to that, the product owner has the authority to cancel a sprint.
What happens in most cases is that the product owner would call a meeting with the team to discuss the new development or problem, and as a team, we would work through those elements and decide what would be the best course of action moving forward.
As soon as the product owner recognizes that the sprint goal is obsolete, or unachievable, they will often address the issue with the customer, the product stakeholders, and the team before making a call.
About John McFadyen
If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.
For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.
If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.
If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.
If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.
#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster
