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.