Posts Tagged Backlog
Making Sense of Tech Debt, Fast
Posted by nthorpe in If we tell you we'll have to kill you on April 10, 2012
Fabio Pereira uses this method to help teams quickly prioritise tech debt. In this example, the team held a Tech Debt retro where they brainstormed all the technical debt they thought they had accrued since the start of the project.
“Technical Debt” is postponed work created when a team takes some technical shortcuts in order to get a solution out fast. These shortcuts create a “debt which must be paid back later. It’s often hard to know where to start on addressing this “debt”.
The team then classified the debt on two axes this way:
“The relative effort that the team would have to spend in order to pay this debt.“
“Pain is the direct impact on productivity that this debt causes. (interest)”
This made it easy for them to decide what to tackle first. “Lets start on the high value work which takes the least effort”!
Fabio says: “One interesting thing that came out of our retro was that the High Return section was almost empty. We came to the conclusion that this was a good sign, it means that we had already fixed most of the LowEffort/HighPain debt during the normal development. Which is exactly how this type of debt should be paid.”
When opportunity knocks…
Posted by fe in Lonely Planet SPP Dev Team on August 26, 2011
I’ve talked about cards that are never going to get prioritised and should end up in the Dead Card Cemetery. But what about small cards that are important enough to keep in the backlog, but that keep getting deprioritised behind other things in the backlog? I’m talking about the really tiny ones, often bugs, no more than half an hour’s worth of work. Maybe you could try an opportunity bucket.
A purist might say that if a card is important enough to be worked on then it will be prioritised into the backlog. But actually, there are always things that have too little value on their own to be prioritised. The team I currently work with created a ‘bucket’ of these at the bottom of their board. Cards get plucked from the bucket if it’s late in the day and not worth picking up a bigger card from the main backlog, or if they’re doing some work in that part of the code anyway and can fix something from the opportunity bucket while they’re in there. It’s proved to be a great way to knock off tiny cards that would otherwise have languished in the backlog.
Spotted: LPOS development team
The Dead Card Cemetery – where dead cards go to die
Posted by fe in LP Content Desk on May 10, 2011
The LP Content Desk's Dead Card Cemetery.
Fe says: “That card might get zombied back into the backlog”.
Some cards just never seem to move up the backlog. They are always deprioritised to make way for something else. After a while it becomes apparent that they are never going to get prioritised, that there will always be something more important. But it can be hard to remove a story from the backlog – someone usually still holds that story close to their heart. It’s a good way of managing team members attachment to particular stories. It almost never happens – but if needed, a card can be brought back into play from the cemetery. It’s also a useful visual to show how many things that we think are really important at the time, actually become so unimportant that they never get done.
Spotted: Lonely Planet Content Desk
Agile Board Hacks 