Sid B. Dane discusses the benefits and challenges of different sprint lengths in Scrum. Shorter sprints (1-2 weeks) allow for more frequent checkpoints, demos, retrospectives, and adjustments. This enables faster cycle times and feedback. However, shorter sprints could increase pressure and reduce time for deep thinking. Longer sprints (3-4 weeks) may provide more breathing room but could reduce team velocity and throughput. The optimal sprint length depends on the specific team and project needs.

1. Sid B. Dane
Capgemini
November 2nd, 2015
Moving to 1, 2, 3 or 4 week SPRINTS
questions, pitfalls, points of attention & benefits

2. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 2
Measuring checkpoint
• Do we currently face the fact that
we need to make a lot of
adjustments?
• Do we often find out that we need
extra stories to
– improve the way we did the
story?
– fix things we’ve forgotten to
consider?
A sprint provides the team with measuring
checkpoints about progress, adjustments
to scope, staffing, forecasts, etc.
The more frequent this checkpoint, the
faster the cycle time for teams to inspect
and make adjustments.

3. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 3
Demo
• How do we currently handle
feedback from our stakeholders?
• Are there enough stakeholders
present during our demos?
• Do our stakeholders feel the need
for the demo?
• Will it help if we have a demo
each 2 weeks instead of 1?
• How satisfied are our
stakeholders with the product?
• How is the demo and stakeholder
availability helping us?
The more often the demo occurs, the more
often feedback can be provided,
incrementally improving the product.

4. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 4
Retrospective
• How streamlined are out
processes?
• How often do we change those
processes?
• Are we at terminal velocity?
• How satisfied are the team
members in general?
• Is that improving?
The more often a team pauses to consider
how to streamline its process, the
sooner it will identify process issues,
attempt to address them and reach
terminal velocity.
How often does the team need a possibility
for people to voice their (general) opinion?

5. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 5
Sprint Planning
• Is reducing pressure and getting
breathing room the reason we
want a 2 week sprint?
• How will we measure the change
in team velocity?
• Are we running lean?
• Should we improve that?
• Will it produce better solutions?
• Do we need that?
The perception that moving to longer
duration sprints will reduce pressure and
provide breathing room without a cost is
a “false truth.” Indeed, it may provide
breathing room at the cost of team velocity.
People will adjust to fill whatever time
they have been given.
We postulate that the smaller the sprint
duration, the faster the engine can run.
Smaller durations squeeze out the fat and
can only run lean. If the team knows it has
up to 3 weeks to perform a task, it may
spend time researching a better solution
than its “first thought” design. If the team
only has one week, it must quickly
implement what can be accomplished in
the sprint.

6. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 6
Commitment
• What is the effect of the absence
of team members?
• And key team members?
• How does the team handle that?
• Are we doing enough to handle
team impact on the absence of
team members due to illness,
vacation and days off?
An argument for shorter duration sprints is
the issue of how the team handles the
absence of a key team member.
Regardless of the reason for the absence,
the general rule is that the team acts as a
unit and must pick up the slack to meet
its commitment.

7. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 7
The Unbroken Think Scheme
• Do the teams have enough time
to think about the solution?
• Are we willing to reduce
production speed to get better
thought-through solutions?
• Do we miss creativity now?
• Do we feel like in a deadline
driven environment?
On longer sprint durations, say four weeks,
the team has 18 unbroken days for the
team think stream.
They have time to dream, be creative,
identify high-risk design issues and
address them, toss out their first or even
second version of an idea and restart again
and again before bringing their ultimate
idea to the demo.
This degree of creativity and the pursuit of
perfection are not to be found in deadline-
driven software development.

8. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 8
Human Nature And Reality
• Do we feel we don’t have enough
time to finish the sprint?
• What would happen if we commit
to less story points per sprint?
• And what if we take on longer
sprints?
• Will we commit to 150% of the
points we currently commit to?
The boots-on-the-ground reality is that the
same thing is going to happen at the end of
the 3-week iteration that happens at the
end of a 1- or 2-week iteration: Time
allocated for testing and preparing for
the sprint review will be squeezed.
It’s more a matter of the team adjusting
what it can do during the iteration duration
and setting expectations appropriately
among themselves than the alternative:
trying to lengthen the iteration so the team
can finish the stories they committed to.
The “better” solution to this point is to
reduce the amount committed to, break the
stories into smaller tasks, pick up more
stories opportunistically, deliver
functionality earlier in the iteration and
allocate time to test and prepare for the
sprint review from the start.

9. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 9
Procrastination
• Do we suffer from
procrastination?
• When do we start to feel the
pressure?
• On what day in the sprint are we
fully up to development speed?
• Why?
The stereotypical college student who is
assigned a research paper at the start of a
semester will think he doesn’t need to
start on it right away; the end of the
semester (or “term”) is many weeks away.
He does other things and comes back to it
about three weeks before it’s due, only to
realize that he is going to need more
hours than are left to produce a good
paper.

10. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 10
Visibility Into Team Challenges
• Does the SCRUM master receive
all of the teams challenges?
• Do we face tough challenges?
• How often?
• Does biting into those challenges
result in failing to meet the
acceptance criteria?
• Is the PO often surprised by
unexpected sprint results?
In the mindset of a stereotypical developer,
when a challenge is encountered in the
course of developing a component, they
put all their energy into solving it.
The developer becomes consumed by the
challenge and doesn’t report it as a block to
her Scrum master; after all, she’s smart
and, in the past, has solved more “hairy”
challenges than this one.
Often, the developer works to solve the
challenge right up to the deadline but fails
to finish it per the acceptance criteria,
and the product owner is surprised that
the functionality was not completed in
the sprint review.

11. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 11
The Story Creation Debacle
• Are our stories ready in time?
• Do we usually make a story ready
to sprint during a 1 sprint period?
• What does that mean?
• Do we take enough time to make
stories ready?
• Are we happy with the quality of
the ready stories?
How much time does it take to make a
story ready to sprint?
Sometimes it’s not possible to get a story
or set of stories ready during one sprint.
A good approach is to extend the time to
create that family of stories across sprints
and provide updates at the end of each
sprint as to where the group is in the
process.
It’s better to take more time for preparing
the story than to pick it up too soon.

12. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 12
Metrics To Consider
• How many points will we take up
every sprint?
• How many do we consider
acceptable?
• Does it give the teams less
pressure?
• To what advantage?
• To what costs?
If the team previously averages 100 points
in one sprint: It is false to extrapolate that
the team will now average 150 points in the
new three-week sprints.
Typically, the team will drop back a little
because it perceives that the pressure is
less; say to 130 points in the three-week
sprint.
The team may now “feel” it has breathing
room, but it was bought with a 13%
reduction in throughput.

13. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 13
Sprinting Ahead
• If we change to a different length
sprint, what problem does that
solve?
• Are there any underlying
problems?
• What alternatives do we have?
You should ask the question, “If we
change to a different length sprint, what
problem does that solve?”
Are there underlying problems, like
personality or behavioral issues that are
manifesting themselves in other ways that
would be best addressed in another way
than changing the sprint duration?
Generally speaking, it is better to set the
cadence and have the team adjust to it
rather than the other way around.

14. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM 14
Challenges Between Different Sprint Lengths

15. About Sprint Length Sid B. Dane, Capgemini, November 2nd, 2015, SCRUM
Source used:
http://www.methodsandtools.com/archive/scrumspringlength.php