Sprint Review Meeting
This meeting is
for the development team to show all interested parties what has been achieved
in the sprint. Literature on Agile often mentions that this should happen by
means of an informal demo of the software. Usually we only demo the software
when we are working on really huge stories that span multiple sprints to show
the progress so far and that we have not been idle in the meantime.
Because we are sitting
quite close to the business owner and many of our customers, we receive
feedback on certain features before the end of the sprint when we hand it over
to the customer to test it and sign it off. For this purpose we maintain
several sandbox database stacks that are reserved for this or that user group.
These customers then use their own sandbox to conduct their tests as to whether
a feature meets their expectations or not.
All this enables
us to keep the sprint review meeting quite short. The main point of the meeting is
to determine if the goals or the sprint have been achieved or not. But even
this becomes clear in the daily meetings before the sprint ends. Usually the
sprint review meeting ends after 10 – 15 minutes and we directly continue with
the sprint retrospective meeting.
Sprint Retrospective Meeting
This meeting is
primarily for the development team and the project manager. Other parties can
be encouraged to participate, but interest has been quite low so far. The whole
point of this meeting is to determine:
- What worked well in the sprint and should be
continued? - What should be continued, and can it be improved?
- What did not work well that we should stop
doing? - What should we start doing?
When you have just
started with Agile development, all analysis from the first 2 – 3 sprints is
less meaningful. At least when it comes to statistics gathered about the
sprint. It’s hard to assess what exactly a story point is and how much actual
time it stands for. There were cases where our estimates have been completely
off and where we had spent days for a task classified as “trivial”. Likewise we
had complex tasks with a high number of story points that took just 1 – 2 hours
to complete.
Furthermore we
made the mistake of taking more tasks onto a sprint than could actually be
completed. This is not necessarily only due to misjudgement on our behalf, but
is also linked to the fact that we act as 3rd line support and that
our highest priority is to ensure a smooth production service. These support
tasks are unknowns that are almost impossible to assess upfront. There have
been sprints during which there were hardly any support tasks, while on the
other hand there were sprints with a significant number of support tasks. But
even if we ignore the support work, we made the mistake of taking too much work
onto a sprint. The result out this was that those tasks had to be carried over
to the next sprint. This is not the end of the world, but still an annoying
experience.
After several
sprints we began to get a feeling for the number of story points
that realistically could be handled in one sprint under good conditions. Also
our assessments in general became more and more precise.
One other effect
that I’ve noticed is that it becomes easier to breakdown complex stories
and tasks into smaller units of work, which in turn enables you to give a more
precise assessment on the task at hand and the sprint as a whole. The result is
that less and less tasks now have to be carried over from one sprint to
another. At least, if we ignore the confounding variable of “support”.
Conclusion
As already
mentioned in the first part, we have used Agile methods more or less even
before we officially introduced them. This probably made the move much less
painful and problematic. In my opinion the move to agile happens to a large
degree inside the head of a person. It is the different mind-set to think in
small iterative steps that quickly and flexibly react to changing conditions,
which sounds easy and straightforward in theory, but occasionally causes
problems in practise.
So far this has
been quite a lot of “theoretical” information. From the next part of the series
onwards I will concretely address what tasks in a database sprint look like in
our organisation, how we changed our whole environment to better address Agile needs
towards testing (unit, integration and regression), and how this all has
changed our release management.
Further information
Below are some helpful links that I have
used to learn about Agile and scrum:
·
Manifesto for Agile Software Development
References:
[1]: http://en.wikipedia.org/wiki/Scrum_(development)
]]>