DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Trending

  • Why Database Migrations Take Months and How to Speed Them Up
  • How Can Developers Drive Innovation by Combining IoT and AI?
  • Comprehensive Guide to Property-Based Testing in Go: Principles and Implementation
  • AI-Driven Root Cause Analysis in SRE: Enhancing Incident Resolution
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Problems With Longer Sprints

The Problems With Longer Sprints

Sometimes it feels like Sprints can get out of hand, and your team just need a little more time. We explain why extending the Sprint is not a good idea.

By 
Daniel Barreto user avatar
Daniel Barreto
·
Aug. 11, 17 · Opinion
Likes (3)
Comment
Save
Tweet
Share
5.7K Views

Join the DZone community and get the full member experience.

Join For Free

Image title

One of the most well-known aspects of many Agile frameworks is the iterative nature of the delivery of working software. The Agile Manifesto states: "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." The key phrase here that many teams seem to struggle with is "with a preference to the shorter timescale." The Scrum guide states that Sprints can be from 2-4 weeks. This is a little bit better, but many teams still gravitate towards the longer end of that range and end up attempting 3-4 week Sprints.

Note: although I am using Sprints as recognized in Scrum for most of this article, I believe the content and practices that follow can apply to any Agile framework.

Why Teams Choose Longer Sprints

There are many reasons (some may even be legitimate) why teams will want to give themselves more time during a Sprint, but usually, these reasons are tied to issues that teams need to confront head on to mature in their Agile adoption. Some of the issues that may force teams to choose a longer Sprint include:

  • Lack of experience or training with story writing, estimation, and sizing.

  • Difficulty communicating between distributed teams.

  • Inexperience with or lack of test-driven development, continuous integration, and other relevant engineering practices.

  • Teams conducting Sprints as mini-waterfall projects (Design first, then develop, and test at the end).

  • Lack of effective prioritization due to an inexperienced or unavailable Product Owner.

  • Not enough understanding or focus on the concept of a minimum viable product (MVP).

  • Product Owner or stakeholder meddling with Sprint Backlog during the Sprint.

  • Team’s fear of upsetting managers or stakeholders by not delivering enough at the end of the Sprint.

  • Team’s fear of having to work overtime to meet commitments.

The Problems With Longer Sprints

Even when teams recognize they have some areas for improvement, they still wonder “is it really a big deal to make the Sprints one or two weeks longer?” It may not seem like much, but allowing teams to adopt longer Sprints can lead to several problems including:

  • Reduced feedback: Teams running longer Sprints will go longer periods without retrospectives and opportunities to obtain important feedback. This will make it difficult to identify and address areas for improvement and will prevent the team from reaching their full potential.

  • Difficulty responding to change: Change can come about quickly and for many different reasons. Whether it’s changes in the market, technology, budget, or business objectives, Agile by its very nature is supposed to embrace change and allow teams to respond to it effectively. If teams are having to wait longer to showcase their work to relevant stakeholders or to receive feedback they will likely find themselves wasting a lot of effort on work that is no longer necessary or relevant.

  • Reinforcement of bad habits: If teams get comfortable with a longer time period to complete their work they may not feel a need to find ways to improve how they are working. If they are not splitting stories correctly or if they are only testing at the end of development and then sending bugs back to get fixed, but they are still finishing their commitments within the longer Sprint they have selected, they may not even be aware there is a better way to do things.

  • Stakeholder fear: Prioritization will become difficult as stakeholders will fear that their changes or features won’t get done if they allow something to be moved to a later Sprint. This will make them more unwilling to compromise on what work will get done or when it will be delivered by.

  • Technical Debt and Integration Concerns: Issues such as technical debt and integration concerns compound the longer they go without being addressed. This can lead to a mad rush at the end of a longer Sprint to address all the problems that have been building up.

How to Facilitate Shorter Sprints

Even when teams agree they should commit to shorter Sprints, it can be overwhelming to figure out how to produce a fully tested and useful piece of working software within such a small timeframe that will provide value to stakeholders. The following are a few tips to help make it easier to manage and complete work during a shorter Sprint:

  • INVEST in User Stories: Many of the issues that teams will run into while completing work during a Sprint will be directly related to stories that have not been broken down into a small enough size or that are not sufficiently independent. Providing teams with training and guidance on how to write stories that are Independent, Negotiable, Valuable, Estimable, Small, and Testable will significantly improve their chances of making realistic Sprint commitments and delivering valuable functionality.

  • Product Owner Training: The importance of the Product Owner to the success of any Agile team cannot be emphasized enough. Ensuring that a Product Owner is properly trained and available to the team to answer questions and clarify requirements will ensure that the team is able to prioritize and estimate stories effectively. In addition, an experienced product owner will know how to properly manage stakeholder expectations and will know the importance of respecting the Sprint backlog that the team has already committed to.

  • Truly Cross Functional Teams: Developing vertical slices of functionality in a short time box is challenging work that requires many different skill sets to meet a typical Definition of Done. For a team to succeed, traditional silos need to be knocked down. Developers, designers, testers, operations, and many others will need to work together throughout the whole Sprint to help make sure that the functionality is not only developed, but also tested and prepared for release as much as possible. Teams can facilitate this by implementing practices such as Test-Driven Development and Continuous Integration to ensure that software is as close to production ready as possible at the end of a Sprint.

  • Continuously Inspect and Adapt: No matter how experienced a team is, there will always be unexpected issues that will make it difficult to complete everything that is committed to during the Sprint. The solution here is not to give yourself more time by using longer Sprints. The way forward is to leverage the shorter feedback loop to take a close look at why a commitment was not met and continuously develop a plan to correct this during the subsequent Sprints.

Transparency and Continuous Improvement

Ultimately, if your teams are declaring that two weeks is not enough time to deliver a piece of working software, it is time to take a deeper look at their current practices and understanding of Agile principles. For teams that are truly committed to adopting Agile, there should always be a focus on transparency and continuous improvement. Maintaining shorter Sprints will enable teams to focus on both.

Sprint (software development) agile scrum

Opinions expressed by DZone contributors are their own.

Related

  • Feature Owner: The Key to Improving Team Agility and Employee Development
  • Variance: The Heartbeat of Agile Metrics
  • Sprint Retrospective Meeting: How to Bring Value to the Table
  • The Agile Scrum Ceremony Most Talked About but Least Paid Attention To

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: