Agile Database Development – The Sprint

In Moving to Agile Database Development I discussed the reasons that led our organisation to
the decision to incorporate Agile methods into our software development. That
part ended with a lead into our first Sprint.

For readers who are already familiar with
development in sprint cycles will the following explanations not be completely
new, but I think it is necessary to explain a few key concepts that I will be
using frequently throughout the article. .

Business Owner

Scrum [1] also calls the Business Owner the ‘Product Owner’.
The Business Owner owns the software and decides on its strategy. He is solely responsible for the
goals, priorities as well as the corresponding schedules and deadlines. In our case the
business owner is also user of the software, but strictly speaking this doesn’t
have to be the case.

Development Team

It is
important to emphasize the word “team”. There is no such thing as a “star”
developer within a team. Everyone is equally important and the success or
failure always reflects on the team as a whole. At the risk of repeating
platitudes, each team is only as good as the weakest member of it. I have
seen quite a few outstanding technical specialists over the last couple of
years who unfortunately turned out to be poor team players. Those developers
were rather detrimental to the performance of the team as a whole and over time
they left for one reason or another and were replaced by supposedly less strong
developers who fit better into the team and in the end strengthened the whole
team. Our team currently consists of:

  • 1 Architect
  • 1 Business analyst
  • 1 Tester
  • 2 Database developers
  • 9 Client developers

The team is interdisciplinary, so for example, smaller database tasks can be
performed by a client developer. One of the full-time database developers will then
review the code and possibly bring it in line with team-internal standards
before it is released into production. Another example might be that the
architect performs smaller tasks in C#.


This is a fixed
term in the Agile literature, however, I don’t really like it and will try to avoid it in
this article. Instead I will place the ScrumMaster’s tasks under ‘project management’.

Product Backlog

The backlog is a
list of requirements that have not yet been implemented. In
our case the backlog contains requirements from the business
owner/customers and the development team. Due to its nature, the backlog is
never empty or complete. Many of its entries arise while working with the
software. Entries on behalf of the development team usually come from
code reviews and/or refactoring after the code has been in production for some
time and is being reviewed in order to keep or enhance stability or

What exactly
should an entry in the backlog look like? Wikipedia gives you the following

“A feature that is added to the backlog is commonly referred to as a
story and has a specific suggested structure. The structure of a story is:
"As a <user type> I want to <do some action> so that
<desired result>" This is done so that the development team can
identify the user, action and required result in a request and is a simple way
of writing requests that anyone can understand[1]”.

This means, that
stories such as “Create an index x for table y to improve query z” do not have a
place as a user story in the backlog. They are technical implementation
details. Alternatively one could formulate it like this:

“As a user I
don’t want to wait for functionality x, because it is crucial to my daily
business.” One result out of this story then might be a concrete task for the
creation of that index. Every user story is assessed in terms of priority.
These priorities range from “trivial” to “blocker”.

User stories can contain more than one concrete task. In such cases we
refer to them as sub tasks of that story. Depending on the complexity of a user
story and the number of related sub tasks, it can well be that this story cannot
be completed within a single sprint. According to the literature, a (sub) task
is a unit of work that shall not exceed 12 hours. If a task assessed to exceed
this duration it should be broken down into smaller tasks. Although we don’t
stick to this recommendation word-for-word, we usually try to break down tasks
as much as possible into logically independent units.

We use story
points as a unit of measurement to assess the complexity of a given task. These
story points can range from 1 to 20. 1 stands for a trivial task, whereas 20
is for a task for which it is not possible to envisage how long it
is going to take or what other tasks might be implied by it. The allocation of
story points for a task corresponds to the level of knowledge of this task at
that time.

At any time, the
backlog represents all known requirements towards a software. The business
owner picks in cooperation with the development team those stories from the
backlog that are to be done during the next sprint. This selection happens
during the sprint planning meeting.

Sprint Planning Meeting

In preparation
for such a meeting, the business owner and the development team go
independently of each other through the backlog and put those stories that they would
like to have onto a list of tasks for the sprint. Scrum calls this list
the “sprint backlog”.

We have developed a practice of assessing stories in the backlog or to review a
previous assessments and modify them while going through the
backlog. This helps the discussion on an item in the planning meeting, because
all participants can directly see whether the given task is considered trivial
or complex. A subsequent review of these assessments takes place later in the
sprint retrospective meeting.

In the sprint
planning meeting itself we go through each story or task in turn and decide whether
or not it should be realised in this sprint. If stories are not clear to
everyone we discuss them up to the point at which it is possible to sufficiently
precisely assess the story. Any further clarification beyond that point is
subject to a separate meeting. Furthermore, we decide if a story/task is to stay
on the sprint list or is moved back into the backlog. Usually this happens by
looking at its priority and at the sum of the already on this sprint allocated
story points. It can well happen, that tasks with a lower priority are moved
into the backlog again, when there are already enough tasks with a higher
priority on the sprint list or if the panel comes to the decision that other
tasks with a similar priority are “more important” and should be given

Although this
may sound like haggling for priorities of tasks it is
amazingly easy and uncomplicated. We hardly have any problems with the
prioritisation of tasks, respectively with moving them in and out of the backlog.
Our sprint planning meeting are time boxed at 1 hour, but usually they end
after 30 – 45 minutes.

Daily meeting

The daily
meeting is the part of the Agile process that I like most. This is where the team meets
with the business owner for a brief exchange. One gets to know the latest
status of the tasks and what each team member is up to since the last meeting
and also is planning to do till the next meeting. The daily meeting usually takes 10 –
15 minutes. It is not an exchange over in-depth technical details, in which the business owner would likely get lost. This is something for separate
meetings or one-on-one meetings. Although this may sound easy, sometimes it is quite
hard to keep focussed on the nitty-gritty without losing oneself in “tech
talk”. This is something that the project manager (or ScrumMaster) should
monitor and step in if necessary to bring the meeting back on track.

Our “dailies”
are not organised in form of a “report to project management”. It may be that
the project manager organises the meeting and also opens it. But from then on
he is not the main person in charge, but rather a moderator. The
main protagonists of the daily meeting are the developers who “report” to the other
developers. They actively shape the meeting. No one waits until he is asked for
his contribution. We rather go through the sprint list and everyone who feels
like contributing to a given item is free to do so. Usually, we kick off with
the items that have been closed since the last meeting, and continue to those that
are in testing/review and then move over to those that are still in development
before finally arriving at the question of who is going to pick up which new
task. We also use the daily to point out as early as possible that certain
tasks are in danger of not getting realised in the sprint, respectively to get
new tasks onto the sprint and push others back when priorities have changed. In
doing so, we take into account, that stories evolve over time and can change

The highest priority
for our team is to ensure that production runs smoothly. If there are
disruptions, corrections have highest priority over anything else until
they are resolved. Only then one can start to pick up the day-to-day business
again. We have gotten into the habit of creating support tasks for every effort
that takes more than 30 minutes. At first sight this may seem additional
bureaucratic effort, but it has the advantage, that such tasks are documented
and are transparent and visible to the business owner and/or other interested
parties such as Change Management and/or Audit who will need to understand why certain tasks have not been completed on time or why certain measures
have been taken to resolve a disruption to production. However, this does not mean
that each team member has to scrupulously record his working time and account for each minute of his working time, but in certain situations
this can be beneficial.

Pages: 1 2


No comments yet... Be the first to leave a reply!