Compute
Elastic Cloud Server
Huawei Cloud Flexus
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Cloud Phone Host
Huawei Cloud EulerOS
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
VPC Endpoint
Cloud Connect
Enterprise Router
Enterprise Switch
Global Accelerator
Management & Governance
Cloud Eye
Identity and Access Management
Cloud Trace Service
Resource Formation Service
Tag Management Service
Log Tank Service
Config
OneAccess
Resource Access Manager
Simple Message Notification
Application Performance Management
Application Operations Management
Organizations
Optimization Advisor
IAM Identity Center
Cloud Operations Center
Resource Governance Center
Migration
Server Migration Service
Object Storage Migration Service
Cloud Data Migration
Migration Center
Cloud Ecosystem
KooGallery
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP Filing
Support Plans
My Credentials
Customer Operation Capabilities
Partner Support Plans
Professional Services
Analytics
MapReduce Service
Data Lake Insight
CloudTable Service
Cloud Search Service
Data Lake Visualization
Data Ingestion Service
GaussDB(DWS)
DataArts Studio
Data Lake Factory
DataArts Lake Formation
IoT
IoT Device Access
Others
Product Pricing Details
System Permissions
Console Quick Start
Common FAQs
Instructions for Associating with a HUAWEI CLOUD Partner
Message Center
Security & Compliance
Security Technologies and Applications
Web Application Firewall
Host Security Service
Cloud Firewall
SecMaster
Anti-DDoS Service
Data Encryption Workshop
Database Security Service
Cloud Bastion Host
Data Security Center
Cloud Certificate Manager
Edge Security
Managed Threat Detection
Blockchain
Blockchain Service
Web3 Node Engine Service
Media Services
Media Processing Center
Video On Demand
Live
SparkRTC
MetaStudio
Storage
Object Storage Service
Elastic Volume Service
Cloud Backup and Recovery
Storage Disaster Recovery Service
Scalable File Service Turbo
Scalable File Service
Volume Backup Service
Cloud Server Backup Service
Data Express Service
Dedicated Distributed Storage Service
Containers
Cloud Container Engine
SoftWare Repository for Container
Application Service Mesh
Ubiquitous Cloud Native Service
Cloud Container Instance
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GeminiDB
GaussDB
Distributed Database Middleware
Database and Application Migration UGO
TaurusDB
Middleware
Distributed Cache Service
API Gateway
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
Multi-Site High Availability Service
EventGrid
Dedicated Cloud
Dedicated Computing Cluster
Business Applications
Workspace
ROMA Connect
Message & SMS
Domain Name Service
Edge Data Center Management
Meeting
AI
Face Recognition Service
Graph Engine Service
Content Moderation
Image Recognition
Optical Character Recognition
ModelArts
ImageSearch
Conversational Bot Service
Speech Interaction Service
Huawei HiLens
Video Intelligent Analysis Service
Developer Tools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Content Delivery & Edge Computing
Content Delivery Network
Intelligent EdgeFabric
CloudPond
Intelligent EdgeCloud
Solutions
SAP Cloud
High Performance Computing
Developer Services
ServiceStage
CodeArts
CodeArts PerfTest
CodeArts Req
CodeArts Pipeline
CodeArts Build
CodeArts Deploy
CodeArts Artifact
CodeArts TestPlan
CodeArts Check
CodeArts Repo
Cloud Application Engine
MacroVerse aPaaS
KooMessage
KooPhone
KooDrive

Properly Planning the Sprint Timebox

Updated on 2024-10-30 GMT+08:00

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 for review and correction, teams can better cope with complex projects.

We use cookies to improve our site and your experience. By continuing to browse our site you accept our cookie policy. Find out more

Feedback

Feedback

Feedback

0/500

Selected Content

Submit selected content with the feedback