SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

Agile Development with Scrum

By Brian Knight,

Agile Development with Scrum

Agile Development with Scrum


We’ve all been there: the project that never ends and no light at the end of the tunnel. Nothing is more disheartening to a developer, DBA or anyone else that may be on a project than a finish line that has no end in sight or worse yet, one that keeps moving. Agile and Scrum development methodologies aim to fix this problem and others by applying what will appear to be common sense after you engage in the methodology for a few projects. This article will get you acquainted with my now-favorite development methodology that can really be used for any project, whether a SOX compliancy, a DBA maintenance, or a standard development effort.


Agile development is a methodology that teaches some very key tenants:


  • Deliver products based on need from high-priority down.
  • Deliver the absolute minimum that the customer wants.
  • Eliminate waste from your projects wherever possible.
  • Deliver projects in short bursts, called iterations.


Agile has sprung many variants of these core believes. Scrum is one of those children that is my personal favorite. Scrum is a rugby offensive term where a team pushes forward to score as a single unit. Scrum is a communication methodology more than a development methodology and because of that, it can be applied to almost any type of project. Scrum consists of the following core believes:


  • The customer lists all the features they want in priority order.
  • Development efforts are broken into 30 day iterations called sprints.
  • Scrum teams are multi-functional teams of 5-10 that contain all the facets of the team that is needed to complete the projects. For example, you may have developers, DBAs and a business analyst.
  • You have a daily stand-up meeting with the Scrum team called the Daily Scrum. It lasts no longer than 15 minutes.


Product and Sprint Backlog

The product backlog is a list of everything the customer wants out of their product. It is in priority order. To kickoff the Scrum process, you have a Sprint Planning Meeting where you spend the first half of the meeting picking what items from the product backlog you can do in the next 30 day sprint with the customer. That list of items becomes the sprint backlog. The last half of the meeting is spent driving down the feature into technical tasks without the customer. Sometimes these meetings can stretch to be 2 hours. The important part of this is to make it a working meeting and engage each of your team members. Once the team accepts its responsibilities for that sprint, there’s very little turning back.


I typically like to have a room with wall-to-wall whiteboards or I’ll put big butcher paper up and draw a grid on it. Essentially the grid will look like this but you can alter it to your liking:


Feature / Story

To Do


In Process



Parking Lot / Descoped

Build a new BI proof of concept







Build a test environment







Improve scalability in SQL environment








 Once you have the features you’d like to accomplish over the next sprint, that list becomes your sprint backlog. You then draw out each technical task it will take to get the three features you have listed in the above grid to a reality. Each feature may have 5 or 20 subtasks under it. An individual task should take no more than 2 days to accomplish. I represent a task with a sticky note and will generally go through a pack per project per iteration. So for the first feature above, you may tasks that look like this:


  • Requirements documentation
  • Build a data model
  • Develop a test ETL process
  • Stub out some stored procedures to access the data
  • Develop a rough UI


Each of those tasks would have a sticky note in its square based on where it is in the chain. I also put a rough idea of how many hours it’s going to take. After complete listing all the tasks on the board, the team then volunteers for their tasks. You may be surprised how well this goes. If some tasks go untaken then a little prodding may have to occur but I’ve never seen this needed. In reality, the above tasks would be pretty aggressive for a 30 day iteration so you may have to scale it back to a lot more stubbing out of items or faking certain data.


Every day the Scrum team meets for a ritual called the Daily Scrum. This meeting should be in the same place and time every day and last no longer than 15 minutes. Any longer than that amount of time will cause people to stop coming. This takes the place of your weekly one hour long status meeting and gives people a general read on the project.


Most people do this in the room with whiteboards around it and the meeting consists of the Scrum master (project manager or team lead) going around the room asking three questions of each member:

  1. What did you do since the last Daily Scrum?
  2. What are you going to do until the next Daily Scrum?
  3. What’s impeding you from completing work?


This meeting is not a problem solving meeting because there’s just not enough time to make that happen. Generally if the Scrum Master sees the meeting going off track with the third question more than a few minutes, he’ll ask anyone interested in this question to wait after the meeting to address it. I like to meet in front of our task chart and move the sticky notes as each person answers the three questions. It adds an element of peer-pressure to hopefully make a person feel they have to move a sticky note every few days.


The Scrum Master takes notes of any roadblocks from work (the third question) and his or her main job becomes removal of those roadblocks. For example, a roadblock may be, “I can’t get the server development group to return my calls on the server configuration.”. In this case, the Scrum Master jumps in and makes the call or escalates the issue. Thirty days isn’t enough time to have too many roadblocks and the Scrum Masters main job is the roadblock removal person. If someone doesn’t have a roadblock for a week, them something may be indeed wrong because everyone has an issue eventually that slows them down.


Remember, not every iteration must go to production but the goal is to show client value in each iteration and when you try to add a new feature, ensure that the client actually will use the feature. I know, this seems like a obvious idea but it’s amazing how many features (82% from a recent poll I read) go unused. If a feature is rather large, break it into small chunks between iterations to ensure there will be adoption. For example, if a client wants a rules management system, maybe you code the rules into the DB in the first iteration and provide them read-only access to them. In the next iteration, you give them the ability to modify the rules. The old adage is small steps, small mistakes.


At the end of the iteration, everyone gets together for an informal Sprint Review Meeting. This meeting is where the product owners, the team and the customers get together to demonstrate what they did over the last iteration. You can also invite anyone else in the organization that you wish that may benefit. This meeting will help steer your team to make sure you’re going in the right direction and is the team’s payoff for such hard work. No matter how high in the organization the customer is, that person should be there to partner with the team and show his or her support. It’s fantastic PR for your team and it puts a face on the customer to the team.


There should also be overlap between you iterations. For example, as the team begins to wind down at the end, they should begin to plan the next iteration to avoid peaks and valleys in work. Instead the goal is a normal 40 hour work week with little overtime.


It’s important to note that you must morph the methodology to what works for you. It may take two or three iterations before you start to see a transformation but you’ll really see the change. In my organization, it fostered an environment of collaboration and got rid of the statement, “I’m waiting on requirements” (where the word requirements can be anything). I’ve used it for both new projects and existing projects that are under way. With projects that are under way, you may have to find a logical line in the sand to begin. Lots of luck and let me know what you think by clicking Your Opinion below.



Total article views: 17037 | Views in the last 30 days: 7
Related Articles

Scrum what are story points

In this blog post I discuss Scrum (agile development methodology) and method to accurately estimate ...


Can Scrum work for the DBA?

Agile! Scrum! Development methodologies! Sprint! If you have a manager who reads any web page abo...


Agile Development with Scrum

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/column...


Day 1: Agile Fundamentals: Scrum, Kanban, Lean and XP

It's week 3 of my jammed packed training schedule this July. This week I'm producing course 918 Agil...


SSIS Project Connection Managers

With the new Project Deployment Model in SSIS developers are gaining the benefit of a new design tim...