ICTShore.com

We re-branded, ictshore.com is now accelerates.it!

Effective Sprint Planning Timebox in 3 Min

Learn something new about Sprint Planning Timebox in this quick article

Share This Post

In this guide, we cover everything you may possibly want to know about sprint planning timebox. We will start to describe the goal of sprint planning, and then see viable options for a proper timebox size. Let’s start.

Sprint Planning Timebox

What is Sprint Planning?

In agile project management, sprint planning is defining a list of objectives you want to accomplish in the next sprint. A sprint is simply a predefined amount of time, generally 2 or 4 weeks. Within this, sprint planning is not about deciding what you will do when within the sprint. Rather, it is just selecting the various goals you want to accomplish in the sprint, and maybe sequence them in case one depends on the other.

In an agile environment, the goals you want to complete in a sprint are called either feature or user stories. They are not the same thing, however. A feature is indeed a functionality you want your application to have. A user story is a description of a component of a feature expressed from the perspective of the user. For example, in a spreadsheet software, a user story might goes like “As a user, I want to be able to add a new column in the middle so that I don’t have to shift all my data”. You then my have a story for other column-related things like removing columns and moving columns around. Those 3 stories can, and should, be grouped into a single feature (say, the “columns” feature).

How does this connect with sprint planning timebox? Before we can discuss timebox, it is important we have a solid understanding of what sprint planning is. This is what this section was all about.

Another important thing to remember is that, with agile, budget and time are fixed, and it is the scope changing. It means that with a given budget and amount of time, we should strive to accomplish as much as possible, but it is what we accomplish that is actually variable. This is in stark contrast with traditional project management, where you have a well defined objective to reach, and your budget and time may potentially vary, but you need to get there.

Since budget and time are both fixed, the concept of timebox can start to take shape. We only need to define the size if a sprint, tat is sprint planning timebox.

How to Define Timebox Size in Sprint Planning

Start by noting that all sprints have the same duration. You don’t define the timebox size sprint-by-sprint, rather you set it once and then all sprints have that size. Considering that the size is fixed, the team can take only a limited amount of work for each sprint.

Sprint planning timebox is a crucible for project managers, because you have to trade off accountability (that comes from shorter sprints) with complexity that can be addressed (that comes with longer sprints). In general, a short sprint size is preferrable than a long sprint size, because you can always chunk down your work into smaller pieces so that part gets executed in a subsequent sprint.

However, your sprint planning timebox can’t be too small. This is because you need to consider all the activities you need to do for each sprint:

  • Sprint Planning – define which features or user stories to address in the coming sprint
  • Sprint Review and Retrospective – look back on the closed sprint and identify challenges and problems you faced, with the intent to learn and avoid repeating mistakes

The shorter the sprint size, the more frequently you will have to do sprint planning and sprint review. However, the longer the sprint timebox, the less effective planning and review become.

The Proper Sprint Planning Timebox Size

With all these considerations, it is time to define the proper timebox size when it comes to sprint planning. I would say the perfect size for a timebox is 2 weeks. This, in my experience, is what works best, especially when you are dealing with great uncertainty and priorities change often.

The proper Sprint Planning Timebox size is two weeks
The perfect size for a timebox is 2 weeks

A 4-week sprint planning timebox can be fine for less unpredictable projects, but most modern projects requires dealing with significant uncertainty and good amount of change. Two weeks is short enough so that you can actually remember what you discussed in sprint planning when it is time to do the sprint review.

For such a timeline, it is a good approach to have 2 hours sprint planning sessions, and only 1 hour of sprint review, unless the sprint had major challenges and failed to deliver, and in that case you may need to reflect more.

The whole goal of sprint planning timebox is to minimize the “management” time spent in meeting and focus more on the work, so having a large burden of meetings on the team agenda’s is never seen in a positive way. One more thing to remember: the larger the team, the more you will need better planning and longer retrospective.

To help you in the sprint planning, it is often important to visualize your user stories. I reccomend using an online platform like Trello, but some teams prefer to use a physical board.

Sprint Planning Timebox in Summary

If you are in a hurry, consider that the best sprint planning timebox size is 2 weeks, including 2 hours of sprint planning before the beginning of each sprint, and 1 hour of sprint retrospective at the end of each sprint.

Sprint planning timebox is crucial for agile project management. If you want to learn more about it, you should start here.

Picture of Alessandro Maggio

Alessandro Maggio

Project manager, critical-thinker, passionate about networking & coding. I believe that time is the most precious resource we have, and that technology can help us not to waste it. I founded ICTShore.com with the same principle: I share what I learn so that you get value from it faster than I did.
Picture of Alessandro Maggio

Alessandro Maggio

Project manager, critical-thinker, passionate about networking & coding. I believe that time is the most precious resource we have, and that technology can help us not to waste it. I founded ICTShore.com with the same principle: I share what I learn so that you get value from it faster than I did.

Alessandro Maggio

2022-08-11T16:30:00+00:00

Opportunity

Project Management

1300