The Case for One-Week Sprints
March 28, 2012 2 Comments
By Mark Bullock – QA Manager – Core Center of Excellence
Cobalt Digital Marketing began using the Scrum Framework development process in summer 2009. We hired a consultant to train the teams, observe meetings, and answer questions.
He recommended that we begin using one-week sprints for several reasons. The team gets feedback quickly. You fail faster and succeed faster. You go through the complete sprint cycle many times so you gain experience quickly.
In my experience those made sense in theory and they were valuable in practice during our transition. The consultant was also able to repeatedly coach the teams to learn agile principles.
You may hear that common practice is to use a two-week or four-week sprint. Why, after more than two years, do we continue to use one-week sprints?
We plan to release our main application once per week. The cadence of the sprints matches our release cadence.
The limited amount of time forces teams to create small stories. We try to limit story size to two days for two people. Small stories are easier to code review and demo.
Most of our teams have members in both the US and India. Product managers work in the US. India staff are hungry for all the communication they can get. They miss some discussions in the US with the product managers, design sessions, and planning meetings. The one-week sprint forces the team to communicate more often in planning, backlog grooming, and demo meetings.
Product owners can see progress and give feedback every week.
Business owners can change priorities for teams in one week or less.
Teams use a two-week sprint several times a year due to vacations and holidays. We have told the teams they are free to choose their sprint length. If they want to change it, they must have clear goals for doing it and a consensus from the team. None have changed so far.