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 scalability.

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

“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 precedence.

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 priority.

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.

Leave a comment

Your email address will not be published.