or Backlogs, accountability & the look on a Product Owner’s face when their New Feature pushes another Feature over the deadline
This article is one of a series on Scrum, The Good Bits.
Scrum has this habit of giving new names to old ideas – status meetings become Daily Standups, requirements become Stories, and the list of things you need to do becomes a Backlog. Every so often someone discovers this and decides it means Scrum is bullshit, and loses the baby as the bath water swirls away.
This is a shame, because Scrum has a whole bunch of good ideas. And some of the best ones – from a developer’s perspective – come from the Backlog.
The Problem We’re Looking to Solve
I had a contract once where we were end-of-lining a platform while they redid the whole thing in Java. The platform was in constant use, however, and we had to keep adding new features (that were ultimately going to get thrown away). Not ideal, but not dreadful.
The other developer was not an easy man to work with, but he was a hard worker and a bright and (technically) talented guy. He was very blunt and far from tactful when dealing with people. But when the internal customer wanted something done, he got right on it and gave it his best shot. Despite this, he’d gotten himself a reputation for being lazy and disorganized.
His internal customer was a Creative, and when he needed something done, he needed it done right now. Even if it was a two-week project, it needed to be done NOW. The developer dutifully obliged – he’d drop whatever else he was doing and get to work on it.
Predictably, nothing got delivered. And because there was no good system for tracking where development time was going, he could also never remember, beyond “Well I was working on it, and then you asked me to work on something else”. Everyone’s the hero of their own story though, and the Internal Customer was sure it hadn’t happened quite like that, and he was the boss, so when things didn’t get delivered, it was the developer’s fault.
Inevitably in software development, items in current development get pushed down in favour of fire fighting. This is especially true in small teams, and also one of the things that Scrum is meant to protect against.
Enter: The Backlog
The backlog is a Todo list with five very very important attributes that differentiate it from a simple list of tasks.
Firstly, every item on there has an estimate in terms of complexity. The estimates don’t have to be perfect, but each is roughly sized in relation to the others, so you know Task A is about twice as hard as Task B. This is useful.
Secondly, the backlog has an order. And items on the backlog must be tackled in the order they’re in – no jumping around and working on something further down the list, unless the backlog is reordered, and this is recorded. This is quite important.
Thirdly, the backlog is prominently displayed, so everyone can see it, and everyone can see when it changes, and the effect those changes have. This list is usually called the “Task Board”. This is important.
Fourthly, the Product Owner or Customer is solely in charge of the order. Not only are they in charge of it, they’re responsible and accountable for it. Yes they should be taking advice from the developers and Project Manager about a sensible way of approaching things, but ultimately, the order in which tasks are tackled is their responsibility. This is very important.
Fifthly, the backlog should have a deadline. This is the most important part.
Traditionally Scrum has three-week deadlines called Sprints. Display your backlog with a deadline, and show the items that will get done before and after that deadline, based on their estimate and the development team’s capacity. Whenever a new item is added before the deadline, display other items that are being displaced by it falling out of the deadline.
The sight of a Product Owner given pause for thought when they see a new feature that’s “absolutely crucial” pushing another “absolutely crucial” feature outside of the deadline is one of the most beautiful moments in software development, and this majestic moment is brought to you directly by the five important attributes above.
When someone comes to ask for a new feature or task or some time drag on the developers, they can insist it goes on the backlog, and is prioritized, where its effects are obvious to everyone.
Feature creep and out-of-band work requests now have immediate, obvious consequences on the delivery date, and these are immediately communicated to everyone (because you displayed the backlog prominently, as per point three, remember?).
Burndown
Burndown is fancy Scrum-speak for “what the developers have been working on, and how long they have left”. The backlog makes a great place for this, and the daily standup an ideal time.
Each day, the developers say what they’ve worked on, and update the estimates on tasks to reflect the percentage they’ve completed, and if they’ve finished working on a task, they say which task they’ll work on next.
Once everyone’s done, the Project Manager (or anyone, really) shows what effect this has on which tasks are inside or outside the deadline.
This keeps the Customer or Product Owner happy, because they can see that people are tackling items in the order that’s most important to them.
This keeps the Project Manager happy, because it uncovers unpleasant surprises about what people are working on, how well they’re working on it, and what’s actually going to be delivered. If something is causing a task to take much longer than the estimate, there’s instant (well, within 24 hours) feedback, and a chance to address this.
And it keeps the Developers happy because they can show they’re working on the right things, day in and day out, without having to explain at the end of six months why it looks like they’re late delivering. Responsibility – and accountability – has been put back in the hands of the business.
Communication is Everything
As I’ll never get tired of saying, Scrum is all about aiding communication – it’s about stopping unpleasant surprises from becoming nasty surprises, and it’s about estimates that work for the business and developers alike.
The backlog is an inspired communication tool for showing the status of a project to the whole team, for showing the developers what the customer (internal or otherwise) really cares about, and for demonstrating the effects of ad-hoc work.
For developers its power is in making their lives easier by allowing them to get on with the work they want to be doing with minimum distraction, and maximum visibility.
