Project Management Stack Exchange is a question and answer site for project managers. It only takes a minute to sign up.
Sign up to join this community
Our team is new to agile. We are in the phase of defining the rules for sprint planning. To start, we are keeping our Sprints at 2 weeks (10 business days). Let's say there is a public holiday in a week: then we are left with 9 business days.
Should the Sprint duration be kept to 10 business days, which means two weeks and 1 more business day? Or should the user stories be chosen in a manner to fit in the 9 business days?
It's usually easier to keep the Sprint aligned with the weeks, so that one can have the weekly reviews on the same days.
It then becomes the Sprint Master's job to check ahead and suggest to the team that they reduce the expected output when the 2-weeks are shorter than 10 business days.
Also keep in mind that the day before and after a weekend are often lazy days with not everybody working a full day; some may leave early the day before and some may come in late after their hangover.
If this is true in your company then the Sprint needs an additional adjustment.
If you do decide that a Sprint length is always a perfect 10-business day Sprint then make sure all the stakeholder are aware that the deadline has moved by a day or 2, or however long. And also figure out how to handle the not-full-days.
Don't assume everybody knows the rules, or remembers them or paid attention when it was mentioned by-the-way at some meeting. That's another reason I prefer to keep it aligned with the week.
Calendar-based Sprint lengths are the norm. The Scrum Guide does not explicitly prohibit capacity-based durations, but says:
Sprints have consistent durations throughout a development effort.
Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Sprints enable predictability by ensuring inspection and adaptation of progress toward a Sprint Goal at least every calendar month.
Calendar-based predictability is strongly implied, but not specifically called out as a framework requirement. However, any attempt to use capacity-based Sprint lengths with variable start/stop scheduling runs the risk of violating key objectives for predictability, reliable cadence, and long-term forecasting.
A key goal for Scrum (and other agile methodologies) is to create organizational confidence through predictability. This includes predictability in event scheduling, as well as long-term predictability about when increments of work will be delivered and inspected. Calendar-based planning is also fundamental to predictable release planning in Scrum!
There's no rule that says you can't maintain a 10-day cadence rather than a two calendar-week cadence, but in pragmatic terms this results in less predictability for standard events. Is the Sprint Review on Thursday this week, or Friday? Or possibly next Monday? And how can stakeholders reliably clear their calendars for a repeating event for the next six months in advance, especially when the dates are likely to change?
In Scrum, as with many agile frameworks, you are optimizing for a predictable cadence, and not for a fixed capacity each Sprint. Team size changes Sprint-to-Sprint as people get sick, take vacation, or join/leave the team. If you take the fixed-capacity approach, you will find yourself forever moving the core Scrum events around in a vain attempt to maintain a stable capacity.
Instead, you should strive to maintain a predictable cadence with variable capacity. This gives the team and stakeholders confidence that the time box is stable, and that the framework events will happen on a reliable schedule even when there are scope or capacity changes.
That doesn't mean you can't shift things for a major holiday or other business reasons. But in practice, you should handle such things by shortening the Sprint to reduce capacity. This makes the reduced capacity visible, creates process transparency, and pays the technical debt of reduced capacity right now rather than hiding it within a variable schedule or "kicking the can down the road."
