Scrum is the form of agile software development that
has helped me the most.
It has helped me to
transform the performance of the web development groups that I've led at
both my current company and at my last one.
sometimes, I do wonder if Scrum is really agile enough?
are quite a few regular meetings in Scrum. For short Sprints, this can
be quite a big overhead. For me, that's where I can see why the Lean
appeals, especially to developers.
there is also value in these meetings. So I thought I'd take a look at
each Scrum meeting in turn, and assess whether or not their value
really outweighs the effort?
First, there is Sprint
Sprint Planning happens before
every Sprint. In our case, that's generally every two or three weeks.
In Scrum, this meeting is split into two parts...
first part is to discuss the requirements for all the User Stories
intended for the Sprint as a team and give everyone on the team the
chance to understand what is required. Questions are asked, and
hopefully answered, that give people useful insight into how each User
Story will be designed. Ambiguity is reduced and the team, hopefully,
gains a common understanding of the User Stories and the requirements
for the next Sprint. The collective experience of the team means that
everyone gets the chance to input and the quality and appropriateness of
the solution is potentially improved as a result. For a 2 week Sprint,
this part of Sprint Planning generally takes about 2 hours, maybe less
if the requirements for the relevant User Stories are well understood or
well prepared beforehand.
meeting, this discussion can still happen ad-hoc as and when someone
picks up a User Story to develop. However, the chances are that the
discussion will then occur with just the Product Owner, or perhaps one
or two user representatives. It will be less onerous than having the
whole team involved, that's for sure, but it won't benefit from the
wisdom of crowds that you get from the group approach to Sprint
Planning. The other thing about this ad-hoc approach is that it's more
onerous for the Product Owner. They would need to be available most of
every day and at the beck and call of the development team. If your
Product Owner is not full-time and sitting with the development team,
Sprint Planning is a useful way to ensure sufficient access to their
time, and it's a useful way to pre-plan this regular event in everyone's
Weighing all of this up, I
personally believe Sprint Planning is costly (in terms of time) but
The second part of Sprint
Planning can happen immediately after the first part, although some
teams leave a day or so's gap between the two meetings, in order to
clarify any outstanding questions before going to the next stage. The
purpose of this second part of Sprint Planning is to plan the Sprint in
The idea is that the team works
together to break down all the User Stories into tasks, and estimate
each task in hours. The team then plans their capacity for the next
Sprint and decides collectively how much to commit to in the Sprint.
I think it is useful to think about the tasks for larger User Stories,
but unnecessary to do this for the smaller or simpler ones. Although
Scrum suggests estimating all of the tasks in hours and going through
this detailed planning process, personally I think this has some
Obviously it can
potentially take quite a long time, and with the whole team involved,
that makes it an expensive meeting. But I also think - ironically - it
can really hinder a team's ability to deliver on time. There are two
reasons for this. Firstly, the team only estimates the tasks it can
identify. They don't estimate the tasks they haven't identified.
Inevitably there are some. Secondly, we all know by now that most
developers are hopeless at estimating. Inevitably it their estimates
will be wrong.
If you're on a large project,
you may have already estimated all the User Stories on the Product
Backlog in Points
in order to get an idea of how big the overall project is. If so, I
personally think it's much more accurate for the team to commit to how
many points they think they can deliver in the Sprint, and stick with
that instead of estimating tasks in hours and trying to plan them in
detail. In my experience, once a team's Velocity (the number of points
delivered in a Sprint) has stabilised, this is a much more accurate way
to gauge what a team can deliver in a Sprint, and it takes less time to
do. For more information on this, see my post The
Secret To Delivering On Time
If the User
Stories being discussed in the first part of Sprint Planning have not
yet been estimated in points, I would suggest the team voting on the
size of each User Story once its requirements have been discussed. Planning
is a great technique for doing this.
in summary, my personal view of Sprint Planning is this: It is
worthwhile to discuss the requirements for the intended User Stories for
the next Sprint as a team. It is worthwhile to estimate the User
Stories in points, either when they go onto the backlog, or using
Planning Poker to estimate them as a team in Sprint Planning. It is
worthwhile for the team to make a collective decision about the amount
of points they are able to commit to for the next Sprint, based on their
experience of their past Velocity. Whereas breaking every single story
into tasks, aiming to identify every task, estimating each task in
hours, working out the precise capacity of the team for the next Sprint,
and committing based on that, is not necessarily worthwhile. It takes a
long time and can lead to less predictability about what can be
delivered, meaning the team doesn't deliver on its commitments and
people are disappointed.
During the Sprint, the
only regular meeting in Scrum is the Daily Scrum itself.
is where the whole team meets every day to answer three basic
- What did you do yesterday?
are you going to do today?
- Is there anything blocking your
This meeting should take between 5 and 15
minutes. No longer.
There is no doubt in my
mind that the Daily Scrum is extremely worthwhile.
keeps the whole team joined up and provides the Product Owner with
clear visibility of progress and any issues affecting the team. This is
one of the key ways that Scrum helps to ensure that development teams
can keep stakeholder's expectations in line with their emerging reality.
This is critically important. The definition of a successful project,
at least in my mind, is one that meets or exceeds expectations.
Therefore I would never personally suggest that a team does not have
their Daily Scrum. It's a way to manage expectations on a very granular
level, ensuring expectations and reality don't diverge along the way.
the end of the Sprint, there are two more meetings: the Sprint
Review and Sprint Retrospective. These are useful meetings,
but because they're at the end of the Sprint, they coincide with the
Sprint Planning meeting which is at the start of the next Sprint.
Sometimes this can make it seem like meeting overload for about 1 day of
the Sprint, which to be honest can be a bit wearing.
purpose of the Sprint Review
meeting is to invite all interested
people to come and see what the team has achieved in the last Sprint.
If this is kept brief and informal, I think it's really nice for the
team to show what they've done. It's also really nice for people
interested in the project that can't be involved all the time to see
what's going on and have the chance to provide regular feedback. This
is another important mechanism to manage expectations in small,
bite-sized pieces, which I've already mentioned I think is critically
important to the success of any project. It's also a useful motivator
for the team to achieve good results in each Sprint, as there will be a
Review meeting afterwards so it tends to keep the team more focused on
And last but not least, the Sprint
Retrospective. The purpose of the Retrospective is to build
continuous improvement into the regular Sprint cycles. Again, there are
three key questions to be discussed by the team in the Sprint
Retrospective after each and every Sprint:
- What went
- What didn't?
- What will the team do differently
in the next Sprint?
Doing these Retrospectives so
regularly throughout a project means that the learnings actually help to
improve the team's Velocity throughout the project (and beyond). If
it's kept simple, the things the team want to do differently in the next
Sprint should be actionable and should actually make a difference to
the efficiency and wellbeing of the team and the project. There's no
question this is a meeting you can't afford to give up. There's just
too much value in it.
However, because it
coincides with so many other meetings at the start and end of each
Sprint, it's important to keep it brief. For a 2 week Sprint, half an
hour should be plenty of time to quickly brainstorm these three
questions and action any changes in the next Sprint.
in summary - whilst on the face of it all these meetings don't seem
very agile, I do believe the Scrum meetings do help the team to
be agile throughout each Sprint. They help the team to gain a common
understanding of what's required, improving the quality of the solution.
They help the team to have a common understanding of progress and
issues, improving the level of teamwork and visibility for the wider
team. They help the team to see what's been achieved, improving the
level of satisfaction and helping to manage expectations. And they help
the team to learn from past issues and improve on them in the very near
My conclusion? Talking takes time.
But it also adds value.