In scrum, timeboxing is an outstanding component. The events are thought to be built in such a manner that it helps teams focus only on the most important topics. It drives team members towards reaching the meeting goal, therefore they’ll take up only the relevant topics that have to be clarified to deliver the required features.
The benefit of timeboxed events is that there’s no time wasted. As soon as the objective of the scrum event is achieved, or if the time expires, the event should end. What’s important in timeboxed events, is to be consistent and not extend the time spent in these meetings, even if there are still things to be clarified.
Still, timeboxing alone is not a useful tool. The team must be aware of what the discussion topics are and what they should get out of that meeting too. And the Scrum Master has an important role in helping the team use this time effectively. Also, scrum proposes a specific duration for each of the events, which is based on the sprint length that can be from 1 to 4 weeks. However, the timebox can be agreed upon with the participants if the proposed options are not suitable for your team, or project context.
Timebox the Sprint Planning event
This event has a crucial role and directly affects the product, so the team must invest time to discuss all the user stories in detail.
As a best practice, scrum says that for a 4 weeks sprint, Sprint Planning should last for 8 hours. The shorter the sprint, the Sprint Planning event will become shorter too. So for a 2 weeks sprint, the team should invest 4 hours into planning the work, and 2 hours for a one-week sprint.
You can also ask your team to propose an alternative timebox they think it’s enough for them to get the necessary information. But whatever you agree on, make sure that you get out of that meeting when the time expires, even if not all topics were covered.
Many times the Development Team tends to discuss too much on a subject, even if there’s no outcome at that point. They simply assume things and build scenarios that aren’t a real need for the business at that moment. So Scrum Masters have to help the team direct their attention more on what’s required and reach consensus before the time expires.
If the team doesn’t manage to do that, then simply schedule another meeting to finish the discussion. Not getting out in time, will lead to long and exhausting meetings where no one will be productive anymore. Finishing the event as scheduled, will also make the team more aware of the time they have and more focused on the right things.
Keep your Daily Scrum short
The Daily Scrum is a 15 minutes event that should take place at the same time and in the same place every day, no matter the sprint’s length. It can be shorter if everything is on the right track, but should not be longer than that.
The 15 minutes timebox is enough for each of the team members to come with updates about where they are with their tasks, if everything is going well or if there are impediments. Clarifications, solutions and other decisions are made right after the Daily Scrum. The people involved in finding the solution should meet and talk.
This event’s purpose is for the Development Team to sync and plan for the day. Being such a short meeting, the Scrum Master facilitation skills are necessary here to make sure the discussion goes as it should. If you are not sure that it’s going in the right direction, don’t be afraid to ask the developers if there will be an outcome when the discussion ends and it’s worth continuing talking about that certain subject, or it should be reviewed at a later time. You can find out more about the Daily Scrum event in this post.
Hold an effective Sprint Review event
What is the timebox for the Sprint Review? The Sprint Review is an opportunity for the entire team to demonstrate what they’ve worked on and get feedback. The Product Owner will capture the feedback and will decide if any of the observations can become future Product Backlog items.
For a 2 weeks sprint, it’s common to timebox the Sprint Review event to 2 hours. The team should show the items when they are complete or partially complete. None of the work that just began should be a topic of discussion. Even if early feedback is what we seek in scrum, the team should present only the work they are confident will bring the desired value.
For 4 weeks, we are looking at a 4 hours Sprint Review event or less. In essence, you just need to have enough time to demonstrate the functionality. Also, to make sure that stakeholders understand the value of the deliverables, and get feedback to know how to proceed with the next sprints. Should we continue following the plan? Should we do any changes to the backlog? All of this feedback from stakeholders is important so that you know how to plan the work further
Keep the team engaged in the Sprint Retrospective event
Three hours or less is the usual timebox for a 4 weeks sprint. If you use to hold 2 weeks sprints, then you should book 1 hour of your time for the event. The team inspects itself and identifies improvements they can bring to the process that will be implemented in the following sprint.
You should have enough time for an activity that allows you to look back and identify how things went, and propose action points for the future. I suggest activities such as “Sad/Mad/Glad” or “Start Doing/Stop Doing/Continue Doing” which allow you to organize better your time because it gives the team clear directions of what will happen. If you are searching for a tool for your retrospectives, Retrium is very nice and easy to use.
Plan just enough time for the Backlog refinement
The scrum framework doesn’t recognize the Backlog Refinement as an event. However, it’s still an activity that is essential for every sprint. This is an activity that helps both the Product Owner and the Development Team.
The Development Team can help the Product Owner in this stage, by estimating the PBIs and identify technical dependencies, to better organize the items in the Backlog based on the priority, taking into account all the technical information as well.
So this should be 1 hour per sprint at least. It usually depends on the number of PBI’s in the Backlog and on the number of sprints the Product Owner would like to have a forecast for. But do not spend more than 2 hours here, or try to forecast too many sprints because the business needs might change and you’ll only be spending time talking about features that will no longer be needed.
Timeboxing is all about helping teams to spend their time efficiently in meetings. It helps you get the value out of each one of these events, without wasting time.
How do you timebox your Sprint events? Anything similar to what you’ve read above? Share your experience in a comment below and let me know if you found this information helpful.
