Updated on 2024-05-31 GMT+08:00

Properly Planning the Sprint Timebox

Background

A team of around seven members uses the Scrum framework. The sprint timebox that the team currently uses is one week. The sprint goals are not always achieved at the end of a sprint. Many work items need to be completed across sprints.

Problem Analysis

Sprint goals are not well achieved, which is currently a problem for sprints. There are several following causes:

Team members face many exploratory work items that require learning costs for those unfamiliar with the work content. As a result, it takes longer to complete work items than usual. The workload of each user story is also heavy, mostly more than 24 hours. The Product Owner (PO) has very high standards on the work item completion, and the review is strict. Unqualified work items are often redone in the sprint. The current team sprint is one week, and the four major events are based on the Scrum framework. The average duration of the sprint planning and review meetings is about 2 hours.

The main factors that affect sprint goal achievement are listed in Table 1.

Table 1 Factors affecting sprint goal achievement (1)

No.

Factor

Analysis

1

Many exploratory work items

Since the status quo is difficult to change, learning costs are mandatory. Team members can share knowledge. As their capabilities improve, learning costs will gradually be reduced.

2

Members unfamiliar with the work domain, requiring learning costs

3

Large user stories

Due to the particularity of work items, user stories are generally large. Split them into smaller stories or create tasks under each user story. Achieve sprint goals at the task level.

4

High completion standards by PO

Further understand and clarify the completion standard by PO, including Acceptance Criteria (AC) and Definition of Done (DoD), in the sprint planning.

5

Short sprint

The team sprint is initially set to one week. If the goal is not achieved as expected, adjust the sprint.

6

Prolonged sprint planning and retrospective meetings

Generally, the sprint planning of a one-month sprint lasts eight hours. Therefore, it is recommended that the planning meeting of a one-week sprint last two hours. Similarly, the retrospective meeting of a one-month sprint normally does not exceed three hours. Therefore, it is a severe timeout for a retrospective meeting of a one-week sprint to take two hours.

Solution

On the one hand, a short sprint leaves little time for work item completion, with team member busy preparing for planning, review, and retrospective meetings. It is difficult to develop emergency handling capabilities and build a stable team. On the other hand, a long sprint goes against the concept of timebox. Therefore, if the team often fails to achieve the sprint goal in a one-week sprint, try to extend the timebox to two weeks. At the same time, adjust the size of user stories to improve the efficiency of the four events.

The sprint timebox extension has many favorable influences, as shown in Table 2.
Table 2 Factors affecting sprint goal achievement (2)

No.

Factor

Influence of Sprint Extension From One to Two Weeks

1

Many exploratory work items

There is sufficient time reserved for learning, exploratory work, and emergencies.

2

Members unfamiliar with the work domain, requiring learning costs

3

Large user stories

The planning meeting is more comprehensive and detailed. User stories are broken down into smaller ones, and tasks are created under each user story. Sprint goals are achieved at the task level.

4

High completion standards by PO

The completion standard by PO, including AC and DoD, are fully understood and clarified in the planning meeting.

5

Short sprint

Team members feel more confident in an empowering atmosphere, with an increase in the sprint goal completion rate.

6

Prolonged sprint planning and retrospective meetings

Meetings are held more efficiently.

Sprint timebox recommendations:

  • One to two weeks

    R&D teams that are committed to time-sensitive products and flexible services require prompt adjustment and regular self-check.

  • Two weeks

    Teams with a relatively stable pace and large stories, which require more time for review and rectification.

  • Three to four weeks

    Teams with a stable pace and requirements.

More about Timebox

In Scrum, the development process is known as a sprint, which is an iteration or cycle usually lasting a month. Sprint is set in a timebox, that is, the sprint has fixed start and end time.

  • Timebox advantages:
    1. Timeboxing is used to control the number of works in progress (WIPs). WIP is a list of work items that have been started but are not yet completed. The development team only focuses on work items that they think can be completed within a sprint, so timeboxing restricts the number of WIPs for each sprint.
    2. Timeboxing requires the team to prioritize the tasks so that they can dedicate their time to quickly completing high-value work.
    3. Timeboxing displays the progress by showing how many timeboxes are required to finish the development of a complex feature. This also allows a team to learn exactly how much remains to be done to deliver the entire feature.
    4. Timeboxing has an end date to prevent endless work.
    5. A sprint has to be finished within a timebox, which means the deadline is definite and cannot be changed. This can motivate a Scrum team to go all out to complete the work of a sprint on time. Without this time pressure, the Scrum team would not have a sense of urgency.
    6. Timeboxing can improve predictability. The team can predict the amount of work that can be completed in the next sprint.
  • A short sprint duration features easier planning, quick feedback, limited errors, and high return on investment (ROI). It helps maintain the enthusiasm of team members and provides more effective checkpoints. The following describes more details about its benefits:
    1. It is easier to plan the workload for a short work period than a long one. Plans are also more accurate and executable.
    2. Fast feedback can help abandon inappropriate product paths and development methods to avoid more cost of poor quality (COPQ). Most importantly, it allows teams to quickly identify and leverage business opportunities that can easily slip by.
    3. Mistakes made during one to two weeks are limited. Even though an entire sprint is a failure, the incurred loss is acceptable. Repeated short-term sprints are good chances for frequent trial-and-error, feedback, and adjustments.
    4. Shorter duration means earlier and more frequent delivery and more opportunities for quick production to generate more ROI.
    5. Short duration helps maintain a high level of enthusiasm. The motivations and interest of a team decline over time. If a project lasts for too long without presenting any results, team members will gradually lose interest. The frequent and quick delivery of runnable products can fill team members with a sense of satisfaction and fuel them to keep working till reaching the sprint goal.
    6. In traditional waterfall development, milestones such as analysis, design, coding, testing, and operation are often less accurate metrics. Scrum provides more meaningful checkpoints (sprint reviews) at the end of each sprint, where team members make judgments and decisions based on the workable features that are demonstrated. With more checkpoints to check and correct, teams can better cope with complex projects.