Some previous blog posts have discussed the importance of a clear backlog for the development of effective business value on your software (or other) project. Constructing a backlog can be a time-consuming and at times overwhelming process. As a result, some teams (especially those less familiar with software development practices) struggle with getting started. However, there is not reason why a very basic version of a backlog cannot kick start the process and deliver some real organization and structure to your problem set or new challenge. Just getting the core of a backlog documented and structured in a simple way will provide a repository for ideas and issues and will help you and your team ask better questions and take basic steps to move ahead. Think Pareto Principle (80/20 rule).
Here I’ve provided the conceptual template for creating a backlog in only 5-minutes. The following 7 components are essential to the most basic backlog and will help you kick off. Once constructed, start adding Bugs and user Stories and you are on your way.
To start, open an excel or word file, create a shared google doc, whatever you like. Create a column with a heading for each of the below and let’s get going…
This is as simple as it gets. Number the first 20 cells of this column from 1 to 20. The order of your backlog determines the order in which things are developed. The key to the priority is that the most important components to the business are next on the list (ie most business value). What makes the most sense to build/resolve first? After that? A lot of factors play into this (see blog post on Prioritizing by Business Value here) but try to think about the order you can organize your backlog in order to always deliver the next most valuable piece. As you move work items up or down the priority, do not change the Order next to it. Whatever moves to the top spot becomes #1 in the order.
User story is the description of what the work is, and who it is for. Try the below format:
As a ____________ I want to ____________ in order to _______.
Ex: As a __cashier__ I want to __be able to open the cash drawer__ in order to __give change to the customer during a cash transaction__.
This format ensures that we understand the user group affected, the desired action and the intended goal of the transaction. It does not describe all the conditions, parameters, limitations, etc. Just the core.
In the case of a Bug, this is a one sentence description of the issue, with BUG at the front.
Ex: BUG: Cash drawer pops out if a Credit Card transaction is selected.
3. Acceptance Criteria
Here is where we identify the conditions, parameters, scenarios, limitations, security considerations, etc. associated to the user story. This section will sometimes be quite long. As you work through acceptance criteria, you may discover that this user story is quite large and actually reflects two user stories. This is subjective, but splitting into smaller user stories helps you have more manageable deliverables and prioritize business value better, so don’t be afraid to do it.
- this should only be available to users who are able to process transactions
- this should only happen if cash transaction is selected
- cash drawer should pop open automatically, but only after cashier keys in amount received
- User should be able to hit a key to re-open the cash drawer, within the same transaction, if it is accidentally closed.
(In this example, we might want to create a new user story for the last item. That way we can work on automatically opening the cash drawer, and adding this more advanced [less common scenario] functionality later.)
Effort is a measure of the degree of effort required to execute a task. This will require your team to start working with the backlog, discussing requirements, acceptance criteria, challenges, etc.
At it’s core, though, choose an effort value between 1 and 13 points. A 13 point item should take 13 times more effort (not time/hours) to complete and should include all work (development, testing, etc.). You should be able to complete at least one 13 point item within a sprint (time box). At first this will be tricky to agree on, but there are techniques like using a sample sized item as a template for future assessments (is this item bigger or smaller than this other user story we all agreed was 5 points?), as well as planning poker (see this article on estimating work for more details and discussion)
This is reserved for Bugs. A bug is an issue/unanticipated/undesired behaviour within something already delivered (a user story). You can create your own standards, but a starting place could be:
Critical – the affected piece is non-functional if this bug is not fixed
High – the affected piece is use-able with difficulty, or there is a less-than-ideal workaround to achieve the same goal.
Medium – the affected piece is use-able, but it creates confusion, does not behave quite as expected, or has some other negative impact.
Low – the affected piece is use-able and this is probably fine, but at some point should be fixed.
Who is taking this item on? Until someone has agreed to take this specific item on, leave it assigned to no one, or the team as a whole if, for example, it needs to be reviewed and worked on as a group.
Where does this work item fall in terms of the development cycle? Is it brand new? Has it been reviewed by the team? Accepted into a sprint? Completed? Developed but not tested or checked by the team? You can customize your list, but here is a starting list (borrowed largely from TFS):
New – brand new, probably not completed filled in (ex: effort, acceptance criteria)
Approved – Completely filled in and ready for the team to look at
Committed – team has reviewed and updated it and committed to complete this item in the current sprint
Resolved – The item is developed, but has not been tested or reviewed to ensure it meets standards and achieves the goals/acceptance criteria of the work item.
Done – Completed, Tested and meets the team definition of done. This item is ready for production, if desired.
A more complete backlog will contain some additional helpful columns such as a simplified name for the work item (shorter than the user story), work item numbers, etc. These are quite helpful, but this basic structure will get you started in documenting and managing your issues, bugs and goals. A high-performing product owner and scrum-master can then turn this into a fully-functioning agile backlog and get your team scrumming like pros in no time. Until you’re ready to start working with a Product Owner to get real results out of your systems, this will help start you off and, at the very least, help you get ready by documenting your issues/needs as you discover them.
No excuses. If you’ve got 5 minutes, you can get your backlog ready to roll.
Jaeger Consulting Group specializes in end-to-end needs assessments and implementation plans for IT systems – starting with analysis and design through to the deployment and training – in order to meet and exceed client goals.