SCRUM - ERNI

ERNI experience reports on management, processes and technology
Experience
nr.54
september 2012
SCRUM
SCRUM: SEttINg
thE RIght CoURSE
Correctly set parameters guarantee
productivity and efficiency.

SCRUM: SEttINg
thE RIght CoURSE
Correctly set parameters guarantee
productivity and efficiency.
With the agile and lightweight
development method
Scrum, large software projects
are more manageable
with respect to functionality,
project duration and quality.
In practice, however, this
will only succeed if the basic
parameters are set in a well
thought-out manner. Among
other things, optimal sprint
length and team size, as well
as the balance between functionality
and quality, are of
decisive importance.
By Bruno HEufEldEr and MiCHElE TEdEsCo
In recent years, agile methods for organising
and controlling software development
processes have gained hugely in importance.
Among the various approaches,
especially Scrum is growing in popularity.
The reason for the increasing prevalence
of this extremely slim framework is that,
when using traditional methods, even
very extensive planning is often unable to
improve management security.
While traditional approaches such as the
waterfall model rely on a detailed master
plan, factors such as self-organisation,
direct and rapid generation of benefits,
continuous status checking and adaptation,
as well as the ongoing involvement
of both users and clients are foregrounded
with Scrum (see Fig. 1).
Yet, although long concept phases as well
as detailed product and requirement specifications
are missing, Scrum is anything
but haphazard: The framework stipulates
a fixed set of rules along with well-defined
roles and a clear and flexible workflow
that is repeated cyclically.
The Scrum framework owes its popularity
primarily to its impressive simplicity.
However, quick and easy as it may be to
learn and apply the principles of the
framework, especially for complex projects
it is critical to correctly set a number
of important parameters.
optIMal SpRINt lENgth
At the heart of Scrum is the self-organising
project team, which, in close
consultation with the client, or prod-
uct owner, implements the sub-tasks
at pre-established time intervals. The
aim of these so-called sprints is to generate
executable functions or modules.
Scrum recommends a sprint length of
one to four weeks. Particularly in large
and complex software projects, however,
there is a tendency towards the
maximum sprint length. This may allow
sufficient time buffers to be scheduled,
but frequently undoes the greatest
advantage of Scrum, namely its
flexibility: The feedback loops grow
larger, as do the response times. Furthermore,
to eliminate errors, the team
members repeatedly have to work their
way back into older topics. New requirements
or priorities, which are
prone to change at short intervals in
large-scale projects, can also cause delays.
Subsequently, forward-looking
and, above all, reliable planning becomes
increasingly difficult.
In the case of short change management
cycles, a sprint length of only two
weeks, for example, is therefore highly
advisable. It allows obstacles as well as
changes by individual stakeholders to
be taken into account at an earlier
stage. Moreover, it forces both the
product owner and the team to focus
on the current target.
IdEal tEaM SIzE
Team size is another key success factor.
The framework stipulates a team of no
more than nine members, always coming
from different disciplines so that
all technical requirements can be dealt

at the heart of scrum is the self-organising project
team, which, in close consultation with the client,
or product owner, implements the sub-tasks at preestablished
time intervals. The aim of these socalled
sprints is to generate executable functions or
modules.
sCruM 16 | 17

figure 1: scrum process overview
product
Backlog
product
owner
Sprint
planning
Meeting
Ready done
Sprint
Backlog
(Priorities)
Scrum
Master
team
1–4
Weeks
Sprint
daily
stand-up
Sprint
Review
Customer
potentially
shippable
Sprint
Retrospective
Scrum recommends a sprint length of one to four weeks.
Particularly in large and complex software projects, however,
there is a tendency towards the maximum sprint length.
This may allow sufficient time buffers to be scheduled, but
frequently undoes the greatest advantage of Scrum, namely
its flexibility: The feedback loops grow larger, as do the
response times. Furthermore, to eliminate errors, the team
members repeatedly have to work their way back into older
topics. New requirements or priorities, which are prone to
change at short intervals in large-scale projects, can also
cause delays. Subsequently, forward-looking and, above all,
reliable planning becomes increasingly difficult.

with autonomously. If the team is too
small, it often lacks the expertise required
to implement all tasks in an optimal
manner.
However, if the team size exceeds the
recommended maximum, communication
problems become virtually unavoidable.
The individual members
are no longer able to communicate
with each other in sufficient detail,
and the decision-making process begins
to stretch out. Accordingly, there
is also the risk of losing focus on the
respective iteration targets.
FEatURE vERSUS qUalIty
Budget constraints, ever shorter timeto-market
cycles and technical complexity
form an everyday part of development
projects. They inevitably contribute
to the tension between
functionality and quality. This often
leads to power struggles between the
product owner, who demands the immediate
implementation of new fea-
tures or requirements, and the development
team, which usually wants to
deliver a high-quality product that
corresponds to the so-called ‘definitions
of done’.
If new functionality, in the form of prototypes
and geared only towards shortterm
benefits, is added to a system, then
what is known as technical debt begins
to accumulate: Over time, imperfect
software design, inadequate or no testing,
unclean code or inadvertent complexity
results in a more and more unstable
system that in the worst case can
bring all further development to a halt.
This dilemma can only be resolved if
all parties involved come to realise
that short-term implementation strategies
will not accelerate a development
project. Experience shows that
sooner or later, the technical debt –
plus interest – will have to be paid back
in order to obtain a clean, expandable
and maintainable system.
sCruM 18 | 19
Example 1
WEll thoUght-oUt dIvISIoN
INCREaSES pRodUCtIvIty
The far-advanced development of a
complex embedded system was threatening
to become bogged down. Over
time, one of the project teams involved
had grown unexpectedly and was finally
greater than recommended for Scrum.
Among other things, this meant that
decision-making within the team was
taking longer and longer, and that it was
becoming difficult to keep to the specified
period of 15 minutes for the daily
Scrum meetings.
On the recommendation of Scrum specialists,
and following a more detailed
analysis of the situation, the team was
split into two teams, each with its own
Scrum Master. Because they continue
to share the product owner and product
backlog, optimal coordination between
the two teams was achieved. Today,
the product backlog is divided be

Team size is another key success factor. The framework
stipulates a team of no more than nine members,
always coming from different disciplines so
that all technical requirements can be dealt with
autonomously. if the team is too small, it often
lacks the expertise required to implement all tasks
in an optimal manner.

tween the teams in the sprint planning
meeting. In this way, each team is better
able to focus on its respective tasks.
The daily stand-up meetings and retrospectives
can now be conducted easily
within the scheduled time in the smaller
units. The bottom line is that the well
thought-out splitting increased efficiency
and productivity, while giving a boost
to the employees’ motivation.
Example 2
ShoRtER SpRINtS pREvENt WoRk
BaCklogS
In a complex, multi-year development
project in a technology company, the
length of the sprints in the initialisation
phase was set at one month. Over time,
it became evident that proper planning
for this interval was becoming ever more
difficult. Planning meetings lasted eight
hours and more due to the large number
of user stories that needed to be prepared
for each sprint backlog.
This led to work backlogs and ever-increasing
difficulties in planning longterm
progress. More and more frequently,
the development team was unable to
meet the commitments which it had
undertaken after each sprint planning
meeting to complete the defined tasks.
After a comprehensive analysis of the
situation, the sprint length was shortened
to half a month. This raised the
question within the development team
how the tasks that had previously failed
to be completed in a month could now
be done in half the time. Soon, however,
the marked increase in efficiency due to
the shortened cycles became obvious:
On the one hand, the duration of the
planning meetings dropped to less than
four hours. On the other hand, the team
was considerably more focused and able
to respond more quickly and efficiently
to unexpected matters, on account of
the now manageable time windows and
the increased transparency. The commitments
undertaken became more realistic
and can now largely be met in time,
which greatly improves the planning for
the overall project.
Erni – innovation in Process and Technology
Bruno HEufEldEr
bruno.heufelder@erni.ch
advisory activity: scrum Master,
agile Coach, Project leader
MiCHElE TEdEsCo
michele.tedesco@erni.ch
advisory activity:
software Engineering,
sCruM, Project Management
sCruM 20 | 21

www.erni-consultants.com/experience
enables & delivers
pUBlIShER’S dEtaIlS
publisher
Erni Management services aG
Zurich · Bern · Baar · lausanne
Erni (deutschland) GmbH, Munich
Erni (slovakia) s.r.o., Bratislava
Erni Consulting España, s. l.
Editor
adela novotná, Erni (slovakia) s.r.o.
Tel. +421 2 3255 37 40
leserservice@erni.ch
www.erni.ch/experience
Editorial office
daniel Meierhans,
inhalte.ch GmbH, Zurich
usG Übersetzungs-service aG, ittigen
Concept/layout
dieter nafzger,
Katarína Beinrohrová
production
von ah druck aG, sarnen
Circulation
10,000 copies (German) + 2500 copies (English)
Published quarterly
issn 1664-4433
Copyright © 2012
by Erni Management services aG
all rights reserved.

www.erni-consultants.com
enables & delivers