We don’t believe in backlogs

In Agile ‘Scrum’ software development, you might have seen reference to ‘the backlog’.

A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.

The product backlog is the single authoritative source for things that a team works on. That means that nothing gets done that isn’t on the product backlog. Conversely, the presence of a product backlog item on a product backlog does not guarantee that it will be delivered. It represents an option the team has for delivering a specific outcome rather than a commitment.

(agile alliance – what is a product backlog?)

There is no backlog in Focust.

In the roots of agile software development, backlogs are nowhere to be seen:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

(agile manifesto: https://agilemanifesto.org/)

We agree with Jason Fried from Basecamp, who says

“We don’t believe in backlogs. Backlogs make you feel guilty.”

(Jason Fried, Basecamp, 2019)

So we don’t have to have them. Good.

In Focust, we don’t have backlogs because backlogs encourage unfortunate behaviour. In our past, we’ve been in teams that have a large backlog of ‘stuff to be done’ by the team. The team sees that backlog and feels guilty or overwhelmed by it. The business analyst and product manager spend a lot of time ‘sorting’ ‘pruning’ ‘reordering’ ‘negotiating’ the backlog. It’s not that the principal of the backlog is bad, but it’s very hard to keep a short backlog, and very easy to spend a lot of time on a backlog. Time and effort that could be much better spent.

Focust teamwork for the next few weeks

If there isn’t a backlog how does a team use focust to ‘do stuff’?

If the product team is going to do a particular thing in the next few weeks, you can make it an area of focus and start planning out the tasks for that thing.

If you have a live product and need to maintain it, perhaps one of your areas of focus is ‘maintenance tasks’. This stuff is important, your team is spending time doing it. It is an area of focus.

If that thing isn’t going to be worked on in the next 2 or 3 months, you don’t need it in Focust. It isn’t important yet, and when it is, you’ll remember.

No backlogs though.

Just a few areas of focus for the next few weeks for the team, to try to have a significant positive impact on the business by meeting business and customer needs.