One dilemma teams face as they are organizing is what approach they should use to determine how long their sprints last. The decision is made more difficult as when most teams start, they are still figuring out many aspects of how they will organize, what tools they will use, and what process they will follow. Compound all these factors with the brutal reality that most teams aren’t very good at Agile in the beginning, and it often leads to a lot of energy wasted on a simple question of whether the team should have fixed length sprints (Time Boxing) or variable length sprints (Feature Duration). Which should you choose: Timeboxing vs. Feature Duration?
Definitions:
Timeboxing: This involves setting a fixed length of time for each sprint, regardless of the amount or complexity of work to be done.
Feature Duration: Where the length of the sprint is determined by the estimated time it will take to complete a feature or set of features.
Suck -----------|-----------|----------|--------- Awesome
Suck: Not implementing either approach.
Sucks a little less: Picking an approach but not sticking to it.
Awesome: Picking an approach that yields the most useful features in the shortest amount of time.
Timeboxing vs. Feature Duration: How to Choose
Disadvantages of Feature Duration-Based Sprints:
Difficulty in Measuring Velocity: Although it’s theoretically possible to measure the work done in hours, Agile emphasizes using Story Points. If the duration varies for each sprint, developing a rough idea of what is achievable becomes challenging, although it’s not impossible. A team could learn over time how many points they could complete in a day and then divide the number of points by their daily average. The issue with this approach is some days at work may be consumed by meetings. Other may be focus workdays. A team could switch to measuring work completed in a week and then figure out the number of days, but the issue still arises that all days in the week don’t result in the same number of productive hours. This significant downside alone could be a deal-breaker, but there are other reasons to reconsider this approach.
Challenges in Scheduling Ceremonies: Setting up ceremonies such as planning, demos, and retrospectives becomes difficult because the start and end of each sprint change from week to week. The logistical effort required for continuous planning meetings alone discourages people from adopting this approach. Establishing a meeting schedule once and only revisiting it semi-annually or annually is more efficient.
Estimation Realities: If there is no system in place, whether you are using Scrum, another form of Agile, or no process at all, it is likely that you are unintentionally using Feature Duration. You are following what seems logical and finishing when the work is done. Even if the team estimates individual work tasks, they typically don’t measure groups of work. The lack of estimation rigor makes it hard to plan.
Advantages of Feature Duration-Based Sprints:
Clear Completion Indicator: The completion of the list of features in the feature duration clearly indicates when the work is done. This provides a straightforward way to measure progress, so you know when a specific set of features is completed.
Convenience for Frequent Releases: Teams that perform frequent releases often find it helpful to group specific features into a release. Feature duration allows the team to consider releases as a logical extension of planning, which can make the process more organized and efficient.
Disadvantages of Timeboxing:
Incompletion of Tasks: Despite the best planning, unforeseen events often occur, resulting in incomplete features by the end of the sprint. Disruptions like illnesses, computer breakdowns, snowstorms, etc.—although individually rare—collectively inevitably cause some issues. This unpredictability makes it challenging to forecast accurately. Some teams quickly give up and consider estimation impossible. It is reasonable to suspect that these disruptions are random and can’t be controlled, but over time, teams start to master many aspects that are within their control. As teams mature, they get very good at enough aspects of the work to accurately plan what work will be completed within a given sprint.
Advantages of Timeboxing:
Consistency: Systems work better and are easier to understand if they are repeatable, predictable, and consistent. Creating patterns that are easy to understand goes a long way toward the adoption of a process. Take, for example, the task of scheduling meetings. Imagine how much easier it would be to set up a single recurring meeting vs. waiting until the last moment to find an opening in seven people’s calendars each week.
Durability: When making decisions regarding process creation, think about what would be easiest if you were absent for two weeks because of an illness or weather event. There would be almost no administrative work to be completed with timeboxing because the meetings, agendas, etc., are set for specific times. This allows for the team to continue independently because there is simply less work to do in your absence.
Other Random Thoughts
Interestingly enough, when I start working with teams, they always think the feature boxing sounds like a better deal. Logically, the work gets done when the work is done, so why wouldn’t a team want to feature box?
Over time, though, if a team is using feature duration-based sprints, they realize it is very similar to what they were doing pre-Agile, and in most cases, that means it isn’t working. They then “learn” to timebox as a team, and with refinements, they rarely look back.
Conclusion
Often, I get asked if there are other options. The answer? Not really. There are regular intervals (Timeboxing) and a list of features (Feature Duration). Teams should be self-organized, and therefore, this decision is at the team’s discretion. As teams form, they may shift back and forth between approaches. I prefer to set fixed-duration sprints (timeboxing) with the teams I work with, except in very specific situations. There are many pros and cons, but the scheduling of common Agile ceremonies alone makes it almost impossible to have variable-length sprints.
コメント