Sprint Length: Not Two Weeks, the Speed of Feedback

What is sprint length for?

Sprint length has two jobs. The first is to keep priorities fixed for a while. The team can then work without debating what matters every morning. The second is to close a loop. At the end of the sprint, the team shows something that works. The user looks at it, and the team learns if it is on the wrong path.

In the first part of this series I wrote this: two-week cycles do not make your estimates accurate. They only let you learn you were wrong in two weeks instead of six months. In that sentence, “two weeks” was an example, not a rule. The real question is how long it takes to learn you were wrong. Sprint length is only one part of that time.

The story of the button on 22 March shows this. The request came on 16 January. It was not ready for planning on 22 January. At the 12 February planning, the sprint was full. It entered the sprint on 4 March, was finished on 6 March, and then waited 12 working days for the review on 22 March. Two days of work reached the user after more than nine weeks. Two parts of that wait came directly from sprint length: waiting for planning, and waiting for the review.

From the field: three lengths, eight sprints each

After that review, I went to the retro with a proposal: one-week sprints. My logic was simple. A shorter loop means a shorter wait and faster feedback. Two people in the team disagreed. We said, “Let’s try it and measure it.” That was the most valuable decision in this story, not my proposal.

We compared three periods of eight sprints each:

• Three weeks: October 2023 – March 2024 (the last eight sprints).
• One week: 1 April – 24 May 2024.
• Two weeks: 27 May – 13 September 2024.

We defined “concrete feedback” narrowly. It is any sentence in the review notes that became an item: “change this”, “this is wrong” or “add this too”. “Looks nice” did not count. The monthly number is feedback per review multiplied by reviews per month: 6.1 × 1.44 for three weeks, 1.4 × 4.33 for one week and 4.8 × 2.17 for two weeks.

The first two weeks of one-week sprints were great, and that delayed the next decision. Finished work waited only two days for the review on average. Next to 7.5 days in the three-week period, this looked like a victory. I wrote in the team channel: “The loop is down to a quarter.” I was looking at the wrong number. The waiting time told us how fast finished work reached the review. It did not tell us whether anyone was there to see it. We only started tracking that second number in the fourth week, when I counted the empty chairs in the room. That is why the most important row in the table is not the one in the middle. It is the bold one: how much concrete feedback we got per month.

Why we dropped three weeks

Three weeks felt comfortable for the team. The carry-over rate was reasonable, and there was no rush in planning. The problem was on the business side. In a brokerage, priorities change with the market and with regulation. An IPO calendar, an announcement from the Capital Markets Board, a campaign. We could not keep priorities fixed for three weeks. On average, priorities changed 2.6 times in the middle of each sprint. Every change meant a half-finished item and another round of planning.

A three-week sprint was not really three weeks. On paper it was three weeks. In practice it was two parts of a week and a half, with a fight in between.

Why we dropped one week

I was the one who asked for one week, and I was the one who ended it. There were three reasons.

Ceremony load did not shrink. This was the math:

                 3 weeks   2 weeks   1 week
planning           3.0       2.0       1.5
grooming           3.0       2.0       1.0
review             1.5       1.0       1.0
retro              1.5       1.0       1.0
daily (15 min)     3.75      2.5       1.25
----------------------------------------------
total             12.75      8.5       5.75
capacity (hours)  120        80        40
share             10.6%     10.6%     14.4%

# note: planning and review do not get shorter in proportion.
# half of a one-hour review is setup and building context.

Planning did not go below an hour and a half, because we had to rebuild the same context every week. The review did not go below an hour either. Even with little to show, the opening, the screen sharing and the round of questions stayed the same. The team went into planning every Monday and into a review every Friday. Mehmet’s retro note in the third week was one line: “We work between meetings.”

The work did not fit. 38% of items did not fit in one week and moved to the next sprint. A slice we could show usually took three to six days. In a five-day sprint, six days of work carries over. Carried-over work is shown half done in the review, and half done work does not create feedback.

The review room emptied. This was the real blow. In the first week, four people from the call centre came to the review. By the fifth week, only one came. Gülay was honest: “We cannot come every week. Call us when you have enough to show.” Our loop had dropped to one week. The user’s loop had not. The slowest participant set the speed of feedback, and that participant had stopped coming.

Why two weeks stayed

Two weeks did not stay because it was the middle option. It stayed because it fell between three separate limits. Priority changes dropped to 0.9 per sprint, so the business could hold two weeks. Carry-over dropped to 12%, so a showable slice fit easily into two weeks. An average of 3.8 users came to the review, because Gülay’s team could put a review every two weeks in their calendar. Concrete feedback per month was the highest of the three periods: 10.4.

How it should work: three questions that choose the length

After the experiments, we tied the choice of length to three questions. In another team the answer could be one week or three weeks. The questions stay the same.

Other things also change with sprint length, and you need to count them when you decide. In the Backlog Refinement part, XS on the T-shirt scale meant “1 sprint”. In the one-week period, XS meant one week. In the three-week period, it meant three weeks. The same label meant work three times bigger, and we only noticed it in the second month. The horizon in Grooming also gets shorter with the sprint. “+3 sprints ahead” means only three weeks ahead with one-week sprints. During that period, the roadmap the team could see almost disappeared.

How we made the switch

We changed the length at the end of a sprint, not in the middle, and we did not stretch or cut that sprint. One week before the change, we did three things. We sent the review invitations again with the new calendar. We rewrote the day values of the T-shirt scale. And the PO told the business that priority changes would now be discussed at sprint boundaries. The third one helped the most. Part of the drop to 0.9 priority changes came from the length itself, and part came from that message. I could not separate the two effects, because we changed both at the same time.

How does it break?

We talked about the second item for a while, and I am glad we did not do it. Work that needs an answer on the same day cannot wait for a one-week sprint either. The answer to that work is not a shorter sprint. It is a separate flow. I wrote about this in the Scrum or Kanban part.

One more mistake. In the three-week period, we also released every three weeks. Finished work waited not only for the review, but also for production. Part of the delay of the 22 March button came from this. When we moved to two weeks, we tied releases to a weekly release train. The sprint is now a rhythm for planning and feedback, not for going live. If we had made this split earlier, we might never have needed the one-week experiment.

The last trap is changing the length often. Every change resets the comparison with past sprints. 20 points in a one-week sprint is not the same as 40 points in a two-week sprint, because ceremony load and carry-over are different. After the experiment we set a rule for ourselves: we do not change the length for at least six months. We have not changed it since the end of May 2024.

What to watch

• Time from finished work to user feedback. This is where sprint length really shows.
• Number of users in the review. If it drops three sprints in a row, the loop is too frequent or too empty for users.
• Concrete feedback per month. Count per month, not per review. Otherwise a short sprint looks better than it is.
• Ceremonies as a share of capacity. If it is above 12%, you are working between meetings.
• Carry-over rate and mid-sprint priority changes. The first says the sprint is too short. The second says it is too long.

Checklist

Conclusion

Gülay’s sentence, “we solved it with Excel in the meantime”, told me three weeks was too long. I read it as “the shorter, the better”. The one-week experiment showed in eight sprints that this reading was wrong. We made the loop shorter and lost the user.

Today we work in two-week sprints. The reason is not that the Scrum Guide or the industry says two weeks. For us, three things meet at two weeks. The business can hold its priorities that long. The team can finish a slice in that time. And the user can come that often. If one of these changes, the length changes too.

The right sprint length is the shortest one your users keep coming to.