The backlog, in Agile terminology, is the list of requirements (or ‘stories’) that are yet to be developed. It can contain the must-haves, the should-haves, the nice-to-haves and everything in between (what is doesn’t contain are any items that should not be worked on: these are put ‘on ice’ and are stored, as you would expect, in the ‘icebox’).
Some of our clients didn’t like the word ‘backlog’ at first because they thought it implied that the project was behind schedule. That’s a fair point. Out of curiosity, looking up the dictionary definition we get two quite different senses of the word.
Backlog: a large number of things that you should have done before and must do now (Cambridge)
This is NOT the sense of an Agile backlog!
Backlog: an accumulation of tasks unperformed or materials not processed (Merriam-Webster)
Yes, that’s more like it and we might at the word ‘yet’ at the end.
So it’s not intended to be pejorative but just a way to store and process future development tasks.
As an agency, we are challenged by the client’s natural desire to engage in a fixed price, fixed specification contract and software’s annoying trait of being a moving target. We approach this by defining what the client currently needs (at the point of engagement) as stories and putting these into the backlog.
The engineers will assign effort points to each task which gives a measure of size to the backlog so we can quote the client a suitable budget for the work. But we also emphasise that the backlog will likely shift and change as the project progresses.
As the client, you can therefore be comfortable that, should your requirements not change, you have been given a fixed price for the defined scope. But so long as the amount of effort remains constant, those requirements can (and will!) change at certain points during the project without affecting the budget.
The sprint roadmap
Looking at the backlog, it is usually pretty clear to the development team how the stories should be grouped and what order they should be developed in. This is a bit of art and experience, but generally we apply the following guidelines:
- Group stories that will be implemented by the same software module (e.g. user-management, registration, login and forgot password stories would be grouped)
- Order modules according to business priorities (e.g. we must have user-management, product-management and client portal to have a minimal viable product, but the discount codes could be added later).
- Order modules according to the chronological user-experience (e.g. if you are new to the system, it helps to see how client registration works before you take a look at the client portal).
- Order modules according to technical dependencies (e.g. the permissions-related stories will be more efficient to test if the user login is already working)
Obviously there will be conflicts but it is usually pretty easy to come up with a consensus priority order that takes these factors into account. So then we just look at the points value of each story group and assign one or more groups to each sprint. Ta da! We have a roadmap.
There are lots of tools for managing Agile backlogs but for us we find Jira with Greenhopper to be the right balance between ease-of-use and power. It has a nice ‘Planning Board’ where we can drag and drop stories into the right order with the story points visible against each story.
As a client, you should certainly be looking for your Agile agency to offer a collaborative tool for reviewing and prioritising the backlog for maximum transparency.
With the exception, perhaps, of technical dependencies, the client should be in just as much of a position to inform the sprint roadmap as the Agile team.
Find out more about SSA working practices on our site