In the software development industry, two-week sprints are the gold standard for Agile teams. We took a slightly different approach for one project I managed at WillowTree, where the client’s timeline compelled us to run the project in one-week increments. Here’s why that was a mistake.
The one-week timeframe required us to push new code live almost constantly, which wasn’t ideal for the development team: they felt rushed and pressured to deliver with minimal preparation and without the opportunity to test or reflect on areas for improvement.
As we encountered in this experience, clients are often pressured to deliver quickly. They equate speed-to-market with success. However, we deliver better products when we give teams adequate time to plan, prepare sprint work, and ensure quality. Development teams, in turn, feel energized, motivated, and ready to tackle new challenges.
Here are some of the real-life examples from this project that prove that two-week sprints do, in fact, work.
Before two-week sprints: inefficiencies and disruptions prevailed.
When we operated in one-week sprints, due to the expected speed of delivery, we couldn’t work in a true Agile Scrum fashion, where work is planned around the goal of shipping a final product. The process was much closer to Kanban style, where work is not planned according to time increments but by capacity and demand.
Our sprints became placeholders for ticket resolution and lacked clear goals around what the client expected us to complete by the end of a given sprint. We had minimal time for the customary Scrum ceremonies — including backlog grooming with the full team, sprint planning, sprint review, or the sprint retrospective. We couldn’t estimate tickets, which were often half-groomed and missing requirements. Jolting, mid-sprint changes caused unnecessary chaos and disruptions, affecting team efficiency and morale.
For developers, this meant limited involvement in planning sprint work. For the client, it meant zero transparency. This was undesirable for all parties involved.
After two-week sprints: more positive outcomes and outlooks.
When we switched to two-week sprints, we experienced almost immediate improvements. Everyone on the development and client team could breathe easier from the get-go. We had sufficient time for all the Scrum ceremonies we had been missing.
Tickets were properly groomed and estimated before we started working on them. We were able to flesh out requirements with the full team and client and ask questions live as a group. These processes significantly cut down on back-and-forth during the sprint, allowing developers to work with fewer disruptions.
Since we could estimate and groom before the next sprint, we could then plan out our work — allowing us to gauge if we were on track. This evaluation helped us share more accurate information with the client about which deployments we expected to deliver and when. On top of that, we could take a minute at the end of every sprint, reflect on what we had done, and continually refine.
Aside from these changes, I also saw improved interpersonal working relationships and a significant shift in team morale. With the return of Scrum ceremonies, developers could directly ask questions and understand where to focus. They shared insights into how the work should be completed, which gave them more agency to help “choose their own adventure.”
In short, implementing the traditional Scrum ceremonies of sprint planning, backlog grooming, sprint review, and sprint retrospective in partnership with the client helped their teams get to know us — ultimately establishing a deeper sense of trust. Having attempted it differently, our teams and clients are confident that two-week sprints improve everyone’s working lives.
