Lots of people make the bad assumption that Scrum project management does not include deadlines and is more of a fly by the seat of your pants methodology. While the lack of paperwork and a solid project plan might make those people who are accustomed to using the PMBOK or critical chain methodology a little nervous, Scrum does include timeboxing, which is a time-management technique that helps you organize the work in progress (WIP) and manage the scope of your product.
I am of the opinion that each sprint should only last from two to four weeks, depending on your project. There are other practitioners who believe it could last longer, but I think when you extend a sprint out past four weeks you start falling back into habits that inhibit your ability to reap the benefits of the Scrum methodology. But we will leave that discussion for another day. Timeboxing, while somewhat controversial when talking with Scrum practioners, can provide you the ScrumMaster, the Product Owner, and your project team with some clear advantages.
When you have a clear start and finish date, first it limits your WIP. Your project team should only include user stories that it feels it can complete within the set limits. You are less likely to gold-plate and add unnecessary features to your sprint. Don’t say that never happens to you — if your project team doesn’t come up with something cool to add during a sprint your product owner definitely will. Having a deadline will force your team to prioritize and perform the work that matters most, creating laser-like focus.
Creating a start and finish date will also more accurately report to stakeholders and your project team the amount of progress you have made in completing an entire feature. I think the burndown chart is one of the more amazing features of Scrum, and outside of calculating the slope of your chart to predict your completion date, timeboxing can help you quantify the progress you are making. I know we would all like an open ended completing date when it comes to development projects, but the reality is most projects still feature a hard constraint of a deadline. If we have estimated the required time or story points accurately, as the ScrumMaster you should be able to accurately estimate your completion date. It will improve your predictions for sure.
I feel one of the strongest benefits of timeboxing is that it helps you avoid unnecessary perfectionism and motivates closure. Instead of trying to get a feature “perfect”, your team should focus on “good-enough” solutions. Because your team has a semi-rigid end date, in my experience they are more likely to focus and complete the tasks they select during the daily scrum. Good and great project teams alike need structure and guidance, and timeboxing a sprint will provide them with required motivation and urgency.
When I go into a project with a team that has dragged their feet on other projects, I always ask a question of the team members and the product owner about their experience with time-boxing. In almost all of the cases, I find that the team did not set timelines for each sprint. Product owners love the idea because they want some predictability in the project timeline. As the ScrumMaster I have to balance a fine line to make sure we deliver and focus on “go fast but never hurry”. While deadlines associated with a sprint may change, it is up to you to know when it is alright to shift those deadlines.