SQL Server Blog

My Blog

Monday, September 02 2013

Keywords: Agile, SCRUM, Database Development, DB, Oracle, SQL Server, Process, Work Items, PBI, user stories

Agile Database Development, Part 1 of 5

As I mentioned in the About page...I have been quite fortunate to work in a very effective Agile development team since 2010, and also quite fortunate to have a manager who has been coaching and encouraging the entire team to adopt proper and pure Agile principles.


I am going to start to write a series of blogs, with whatever thoughts come to my mind at the time of writing, on the subject of efficient Agile database development that has actually worked for my team and I. I don't claim that these practices will help your particular team, company or situation, as all companies have different requirements and all teams have different chemistry, maturity level, expertise level, the right mix of specialties and needs.


*) Lesson 1: Business Value
You should not create a user story like "Create procedure..." or "Create table..." or "Customer's stored procedure..." etc. Your database tasks should be attached to a user story that has business value and is demo-able.
Example: Create Customer
Then within that user story, you have a little GUI task, some middle-tier job, and some database related tasks, just enough to get the story done, just enough to add a new customer...not to update or delete it etc.


*) Lesson 2: The Thin Slices
You need to partition the user stories so that they get the smallest possible, and still be able to do the entire required database work within that story.
Per example, let's take a simple feature like "Customer Maintenance. The user story "Create a Control Panel" is an epic user story. User story "Manage Customers" would also be too big by itself and should either be broken down or be created as the parent user story of "Create Customer", "Update Customer", "Delete Customer", "View Customer" user stories.
Make the user stories the thinnest possible.


*) Lesson 3: Proactively fix the ever failing Unit Tests
When your refactor some code, and some of your existing unit tests start failing...either fix them within the present sprint, or at the latest by the next.
Make it a rule not to go more than 2 sprints with failing unit tests...even if you think you know the causes and that they would be easy to fix.
Unit tests should be taken seriously.


*) Lesson 4: Separate user story for each database type
Create a user story for each database type your application supports. Per example if your app supports Oracle as well as SQL Server, then create "Add Customer (SQL Server)" and "Add Customer (Oracle)" user stories. This way they could each be created and tested separately. If you put them together then that'll make the user story too large and there'll be no guarantee that it'll finish successfully within this sprint. So you need to apply the 'thin slice' rule on multi-database development scenarios.
Try to do all these related PBIs within the same sprint. At worst case, do them on the very next sprint. Do not put too much gap between them. Don't completely get all the SQL Server user stories done for 10 sprints, and then attempt to convert all to Oracle. That'll be a great mistake and a huge risk to take.


Most of the above-mentioned recommendations apply not only for developing databases, but for any other kind of development as well. It's Agile: it's just common sense!





Written by Montreal DBA Team