How One-Week Sprints Transformed Our Engineering Workflow at Allstacks

Making The Decision to Change

The decision to move to one-week sprints was bold and came from our engineering team, who saw the potential benefits of making smaller, more manageable commitments. This idea, while it had seemed daunting in the past, was immediately embraced by the team. The product team was stoked, having seen first hand on many occasions the value of short, intense design sprints and hackathons.

"In the past, when we floated the idea of one-week sprints, it fell flat. There was a perception that such a rapid pace would be too demanding and dominated by twice as many ceremonies. However, our actual experience proved this to be a misconception." — Graham Langdon, Product Director at Allstacks.

In hindsight, our team was well-suited for this change because we are fairly self-sufficient. We have a dedicated QA person, the team is full stack and can work anywhere on the codebase, and we have design and UX embedded within the team. This independence allows us to manage our tasks effectively within the shorter sprint cycles.

"With one-week sprints, it’s been easier to integrate important customer requests and bug fixes into our schedule. We’ve improved our focus and collaboration, and we have twice as many opportunities to update our plan based on weekly reflections." — Graham Langdon, Product Director at Allstacks.

Implementation

Transitioning to one-week sprints required adjustments in our processes and team dynamics. We streamlined our planning sessions, worked on more thorough task breakdowns before committing to work, and started coordinating all our follow ups and slack huddles with more urgency. Although there were initial concerns about increased pressure and meeting deadlines, the team readily adapted to the new way of working and the change proved to be less daunting than anticipated.

Challenges Faced

While we anticipated some challenges, the team quickly adapted to the quicker pace and tighter deadlines. The initial reluctance was more in our heads, and once we started, the transition felt natural. In hindsight, in the months leading up to this change we’d honed our process a lot and gotten especially adept at task breakdown. The biggest challenges we had to overcome were:

Finding our rhythm: As we move faster, we find ourselves needing to move or consolidate a meeting more frequently to accommodate schedules. As a result we’ve gotten more comfortable with flexibility.

Staying disciplined: Moving faster can make it easier to skip steps. We did end up falling short on our goal of estimating all the work we do in the last month of Q2, which became immediately apparent on our team’s Allstacks dashboard. We’re paying closer attention to this now.  

Maintaining our culture: We didn’t want going faster to compromise the awesome culture we’d built on the team. We’ve managed to increase the healthy sense of urgency without burning out. Weekly retrospectives has no doubt been a big help here.

"In the past, when we floated the idea of one-week sprints, it fell flat. There was a perception that such a rapid pace would be too demanding and dominated by twice as many ceremonies. However, our actual experience proved this to be a misconception." — Graham Langdon, Product Director at Allstacks.

Benefits

"Practicing the same activities every week means we get twice as many opportunities to hone our skills. Weekly repetitions ensure we are always prepared and in the right mindset for planning, refinement, and review." — Graham Langdon, Product Director at Allstacks.

• Improved Task Focus: With shorter sprints, our team concentrates better on the tasks at hand. The focus on smaller chunks of work has led to more efficient task completion and a noticeable increase in productivity.
• More Accurate Estimations: Breaking down tasks into smaller, manageable chunks that fit within a one-week sprint has improved our estimation accuracy. This avoids the pitfalls of overcommitting and under delivering.
• Better PR Cycles: Merging code more frequently feels really healthy as in the past we've had really long PR cycle times and many PRs open at a time waiting for review. 
• More Effective QA: The QA effort is smaller on smaller stories. The smaller increments mean we find problems and make adjustments more often, leading to higher quality of work in the long run. We all help with QA, so smaller increments to test make it easier for everyone to understand what needs testing and jump in. Previously we’d have a lot of stories that were so daunting to test we found ourselves feeling reluctant to get started. 
• Responsive Bug Management: One-week sprints allow us to address the next due bugs weekly, making it easier to manage our bug SLAs and respond promptly to customer requests.
• Bugs are being addressed more quickly. Previously, I'd ask for progress updates throughout the 2 week timespan for our P3 bugs. However, since moving to 1 week sprints, I know if a bug is in that sprint, it's going to be resolved within 5 days so there's less of a need to ask for eta. This trust is also built on the fact that our team has been completing the items they've committed to/added to the sprint. — YoungIn Attucks, CSM
• Shorter Stakeholder Feedback Loops: The weekly cycles have created more opportunities for stakeholder feedback and course corrections, which has been crucial in maintaining alignment and updating our roadmap.
• The CS team has really appreciated getting access to new features more frequently. Even if a feature may not be 100% customer ready, the fact that we're able to demo and show what we've done so far has been helpful in sharing the product vision with customers, getting their feedback so that if we need to pivot, we can do at those increments. — YoungIn Attucks, CSM at Allstacks
• Alleviated Pressure: Ironically, two-week sprints felt more pressurized because they felt like big investments. If we missed our goal, it was a failure for the entire two weeks. With one-week sprints, the pressure is less intense. We have more frequent check-ins, reducing the anxiety of disappointing stakeholders over longer periods. This healthy pressure fosters tight feedback loops and continuous learning.

“It's been a win across the board. Our stakeholders love that our sprint ceremonies are lightweight and productive. The delivery team loves they can quickly incorporate feedback and customer input blowing up a sprints scope. Ultimately, our customers benefit from better visibility and support for their needs.” — Mark Mulholland, Product Manager at Allstacks 

Potential Drawbacks

• Harder to Keep Everyone in Sync on Changes: The more rapid pace of change means updates to documentation and messaging needs to be more rapid as well. The benefits of the faster pace outweigh the cons for us, and we’re working on ways to tighten up the communication as well.
• Impacts to Stakeholder Calendars: When we made the change to one-week sprints, we decided to invite fewer people to sprint review. This made our sprint ceremonies more intimate, which has its advantages. While this helped us be more nimble and allowed feedback to be honest, it also meant fewer people are in the loop about new developments. Going forward we’ll likely be experimenting with broadening the invite list again to find the sweet spot.
• Increased Frequency of Meetings: One-week sprints require more frequent planning, review, and retrospective meetings. This can initially feel like it reduces the time available for actual development work. Teams need to be disciplined in managing their time effectively to avoid meeting fatigue.
• Pressure to Deliver Weekly: While the pressure in one-week sprints felt healthier for us, there is still a constant need to deliver something valuable every week. This can be stressful and may lead to cutting corners if not managed properly.

Are One-Week Sprints Right for Your Team?

One-week sprints have been awesome for us, but the change your team needs might be completely different. Here are some things to consider if you want to try one-week sprints:

• Self-Sufficient/Full-Stack Team: Ensure your team has within itself all the functions it needs to be successful (development, QA, design, UX) and doesn't depend heavily on external teams to complete their work. If this isn’t the case for your team, work on this first.
• Leadership Buy-In: Strong support from leadership and a willingness to embrace dramatic change are crucial. If your team is enthusiastic and open to experimenting, the transition is more likely to succeed. That said, don’t let an inflexible system be an excuse to not innovate. There are always creative ways to push the envelope.
• Effective Communication: Frequent and clear communication is essential to manage the increased cadence of meetings and deliverables.
• Flexibility and Adaptability: Your team should be able to adapt quickly to new workflows and be willing to continuously improve processes.
• Strong Task Management: Ensure your team is skilled at breaking down tasks into small, manageable pieces that can be completed within a week.

Conclusion

Shifting to one-week sprints has had a profound impact on our team’s productivity, estimation accuracy, and overall workflow. While the transition posed some challenges, the benefits far outweighed them. More importantly, this experience underscores the value of experimentation. If you're feeling constrained by the status quo, take a leap, try something new, and see what you learn. Even within the constraints of a larger organization, there are always opportunities to innovate and improve.