What Does Your Backlog Say About You?

If you review a backlog it will intentionally or not reveal a lot about a team, its priorities, its values and the future its heading towards.

An even more fascinating aspect to this window into a teams inner workings is that if you were to tell the team what you think it says about them they would more than likely disagree.

This ability to analyse teams isn't some sort of mystical unexplainable art, its the drawing of logical conclusions based on the work the team chooses to prioritise as well as the apparent goals and motivations behind having this work on the backlog in the first place.

What You Don't Value

If you asked a team do you place value on stability, security and sustainability you would very much expect to see a room full of nodding faces.

However the make-up of stories pulled into sprints can very often tell a different story.

Teams will often have a strategy around how to deal with tech debt or security issues and the need to balance this with continued feature development. When a team has these issues under control they are able to maintain this forward momentum in a sustainable way while users continue to make the most of whats on offer.

Teams whose backlogs demonstrate significant technical debt who then continue to prioritise new features are sending a message which while inconvenient is none the less true.

It sends a message that the team intends to move forward regardless of whether or not they are taking their users with them and regardless of whether or not the direction they are heading in is built on sustainable foundations.

It places little importance on issues currently being faced by users, while users are facing issues with functionality already deployed this should the be number priority of any team. Promising users jam tomorrow is very rarely an effective strategy.

Something Like

A backlog should not simply be a place to register ideas or represent a to-do list.

A backlog should be a list of well defined work items that have definite value either to your users or to you as a business. All of these work items should be ready to go should the team be in a position to start work, it shouldn't be necessary to filter the backlog to find these work ready items or spend a time demystifying what is required.

Obviously coming up with this list of work items is an iterative process, it isn't possible to instantly define and document requirements or the technical implementation that will fulfil them. But this process should take place outside of the backlog and must be disciplined enough to only migrate items to the backlog once they have progressed to the ready state.

A backlog full of half thoughts or reminders about functionality that may or may not be useful will struggle to keep your development team productive and also fails to demonstrate a clear strategy for the product being developed.

Requirements can change and items on a backlog aren't fixed in stone but this doesn't mean they can't always be descriptive of whats required at a moment in time and be ready for implementation.

Spaghetti Stories

User stories should ideally be independent of each other, this should enable a backlog to be fluid and allowing teams to quickly re-order work items depending upon prevailing priorities.

It maybe that stories are inter-related in terms of delivering an end-to-end feature to a user but the ability of the team to work on them shouldn't necessarily follow the same inter-connection.

This is not always easy to achieve and can have as much to do with the architecture of the code base being worked on as the teams ability to craft stories.

But disorganised teams or teams that lack a clear direction are likely to construct a backlog that becomes rigid, this can be seen in sprint planning activity when the team struggles to put together an effective sprint because of blockages on certain stories causing a ripple effect through the backlog limiting the amount of work that is ready to pull in.

This can also make it difficult to identify the next shippable version of the software, this isn't always necessarily when the next feature is ready but the point at which a group of changes can be made to the code that move it forward whilst allowing it to be stabilised.

A key skill for any agile team is the ability to map a path from story to story delivering software with value to users and the business along the way.

The backlog and the sprints it drives are the heartbeat of an effective team, it is more than just a collection of work items it should be a manifestation of the strategy the team is following and the direction it is heading in.

As much as it can reflect the success of a team it can also be indicative of its failings. Because of this teams should take the time to asses the health of its backlog and attempt to draw conclusions on what could be improved or to emphasise what is working well.

Treat your backlog as n indication of the agile health of your team, treat it with the respect that you afford your codebase and keep a keen eye out for signs that the quality of its stories are on the decline.