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 (Although I am using sprints as recognized in Scrum for most 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 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
· 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 if 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 let something 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 satisfy 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 not to unnecessarily introduce changes to 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 skillsets to meet a typical definition of done. For a team to succeed, traditional siloes 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 production ready 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.
Daniel Barreto 