DBA Backlog

As a Database Administrator both in projects and daily routines like administration or operations all kinds of things show up. Normally they are associations that doesn't really fit in the plans or the context, but still relevant or even important in the long run.
Usually these things and ideas end up on post-it notes, whiteboards or another volatile medium. If you are lucky to be in a large project with experienced developers and project managers some items might be saved.

Another way is to create your own backlog of ideas, points of interest, nice to haves and other things that might make your works better. In ITIL these things will be considered part of Continual Service Improvement (CSI) as input to the Plan part of the Deming Circle.

I have collected a set of attributes I have used to establish a backlog in a project or a team. Not all attributes are relevant in each situation. Sometimes it is also necessary to twist an attribute to make the backlog usable.

And to my proposal for a general backlog:

Attribute Name	Attribute Description
Title	Short and descriptive title of the backlog item.
Theme	Predefined themes to sort the backlog on a "dimension" like technology. This is very useful when the backlog grows. { SQL Server | SSDB | SSIS | ... }
Description	Prose description of the backlog item with as many details and thoughts as possible. The description can easy change and grow over time, even before the backlog item is activated and processed.
Priority	The priority of the backlog item. Predefined values that makes sense, even to senior management. { Critical | High | Medium | Low }
Abstraction	This item can be added to the backlog if you are working with defined abstraction layers from idea to solution. This is sometimes seen in agile development methods like SAFe. { Epic | Story | Task }
Status	Status of the backlog item. The values are inspired by Kanban to support an effective execution of the backlog. "Keep the Ready queue short". { Backlog | Ready | Doing | Done }
Estimate	A quick estimate of the time needed to process and finish the backlog item. The item is finish when the issue is solve and documented – completely. As in agile development. { Day | Week | Month | Quarter | Year }
Deadline	Date of deadline, if one is required. If a deadline exists it is usually given by business or management.
Changed	Timestamp of last change to the backlog item. Consider to enable automatic versioning on the backlog.
Created	Timestamp of when the backlog item was created. Usually when the item was entered into the backlog.
Changed by	The person who last changed the backlog item.
Created by	The person who created the backlog item. Usually the person who entered the item into the backlog.
Tangible	This is more a business attribute that tells about where business can relate to the backlog item.
Owner	Business owner of the backlog item.
Responsible	The person who is responsible on the backlog item. Usually the person who is to get the job done.

I personally have good experiences on building a backlog as a SharePoint list rather quick and effective. This also gives all the SharePoint features on filtering, printing and other trivialities.
Another possibility I have tried a few times is using the backlog features i Microsoft Team Foundation Server (TFS). It works really nice also for Database Administrators.

History

2017-04-02 Blog post created.
2017-05-08 Abstraction element added to backlog schema.