scruminfo.com

Why are fixed length sprints (iterations or timeboxes) of the same duration important?
why should these sprints not exceed a 4 week timebox?

WHY 4 WEEKS?

Scrum recommends that iterations do not exceed 4 weeks. I have heard of some implementations using 6 weeks. I stick with durations of 4 weeks or less.

4 weeks of fixed scope is not too much and it does not overwhelm our customers, stakeholders and team members with huge amounts of information. Our feedback for an acceptable amount of work is manageable. We can focus on a small the amount of work to achieve our outcome and deliver this to the highest level of quality. If we had iterations of 3 months we introduce to much complexity and unknowns, the horizon is too far off.

Fixing a defect on 4 weeks of work is much different in cost and complexity to fixing a defect on 3 months of work. 3 months will most probably result in more defects anyway.

FIXED Vs VARIABLE LENGTH ITERATIONS

I have seen and fixed an agile implementation where the iterations started off fixed but ended up variable. This is a bad practice and should be avoided at all costs. Software product development contains so much variability and hidden unknown nasties. Adding another dimension on variability is just going to make things more complicated and painful.

“Oh its just another week and we can get these 2 done”

“I know we have added 2 weeks to the iteration, its been 6 weeks now but really one more week wont hurt to just get these 2 new stories done, they are very important you know”

So this goes on, rinse lather,repeat.

Variable length iterations guarantee behaviour where stories will be added to the iteration because it allows it, resulting in:

• the iteration deadline and scope moving on a regular basis
• disruption to the team and their committment to get work done, “aaagh I just want to achieve our goal, now more work, i did not commit to this, we need to have a meeting as we need to estimate this now”
  disruption to planning and meetings e.g.

“oh sorry no we are not finishing Friday we are now finishing next Friday, ill re-schedule the retrospective meeting”
“I know the product owner accepted but the meeting has changed to next week, oh is he in London next week?”
“No we cant demo when we said we have added another week”

• an increase in the amount of scope that the team must focus on
• forcing the iteration goal to constantly change within the iteration
• making productivity metrics more complicated than they should be

With a fixed duration we never miss the deadline, the time never moves, if productivty is affected then and only then do we remove work or add work and slightly adjust the goal, but we never miss our deadline. This gives the team a good feeling of always achieving something. As time passes the team will begin to get a natural feel for the capacity of work they can do in a timebox and their estimation will become more accurate.

Fixed iterations simplify planning and reporting, especially velocity. If we have consistent 4 week iterations then we dont need to adjust velocity. The only option we have is to use yesterday’s weather for planning, its the last bit of fact we had.

For example:

Iteration 1 4 weeks Velocity = 30 points
Iteration 2 1 week velocity = 12 points
Iteration 3 3 weeks velocity = 20 points

Iteration 4 is 4 weeks long so how many points are we going to use to select the initial stories for the iteration, cant use 20, now we have to come up with some calculation dont we, keep it simple:

Iteration 1 4 weeks Velocity = 30 points
Iteration 2 4 weeks velocity = 34 points
Iteration 3 4 weeks velocity = 48 points

The reason why iteration 3’s velocity has improved is that the team is becoming very knowledgable in the technology and product , productivity is increasing.
So for Iteration 4 lets select around 48 points of work for the iteration planning meeting.

RYTHM IS NOT JUST FOR THE TEAM

A constant iteration cycle gives our team, customers and stakeholders rhythm in knowing when iterations are finishing and starting. Every 2 weeks the stakeholders or business get to see working software, every 2 weeks they get a product burndown chart. Every 2 weeks we re-adjust the plan, the release, the communication to sponsors, finance and executives etc. Every 2 weeks they get a realistic picture on how the product is evolving and can continiously make decisions based on fact.

“Its the end of another iteration on Tuesday, thats great we will see some more working software.” Can you imagine a situation of “How long is the current iteration? when does this one end?, Oh is this one 4 weeks. Why was the last one 1 week?”

Iterations of the same duration simplify:

Resource Planning
Financial Planning and Budgeting
Release Planning
Meeting Invites
Productivity Metrics
Reporting

PRIORITISATION OF WORK, WE DONT WANT TO WAIT TO LONG

Product requirements will change and priorities will change. While the team is progressing during an iteration, if a high value item is realised then the business only have to wait the remainder of the current iteration before it is worked on, and this is acceptable. Its not a long time to wait.

Imagine a scenario where:

Iteration 1 is 2 weeks
Iteration 2 is 1 week
Iteration 3 is 4 weeks

In Iteration 1 our stakeholders re-prioritised a product backlog item as high value and were told that we will be working on the high value item in 2 weeks.

On day 2 of Iteration 2 our stakeholders realised a new high value feature and were told it would be worked on next week.

In Iteration 3 they had to wait 4 weeks. On each occasion they were given a different answer.

MULTIPLE TEAMS

Consistent duration between multiple scrum teams makes synchronisation and integration far easier. Imagine the following:

Team 1 (The bad team)

Iteration 1 - 2 weeks
Iteration 2 - 1 week
Iteration 3 - variable

Team 2 (The good team)

Iteration 1 - 4 Weeks
Iteration 2 - 4 weeks
Iteration 3 - 4 weeks

How are these teams going to:

synchronise work and releases
integrate streams
rebase code
report on overall progress

Fixed iterations of the same duration provides rhythm and consistency to all areas in the product development cycle and fosters a common and simple understanding for all parties be they Stakeholders, Customers, Sales and Marketing, Finance or members of the product development team.

Filed under: Scrum Articles