Trash your projects
A pile of papers was standing on the desk. It contained all the mail correspondence received during the last three months. When my car had been paid in full, the car title was sent by regular mail. It had happened two months before. Now I needed it to sell the car, and the car title was lost in the pile of papers.
That title had to be somewhere. Maybe between a home security system promotional offer and a grocery store flyer? When they got in the mail, I reviewed and stored them all, since I thought I might need them later. "You cannot throw opportunities away!", my grandmother used to say when her family made it through the world war II.
The pile of papers contained dozens of assorted, mixed, and almost inevitably expired coupons. I had lost time to take those coupons out of their envelopes, to order and store them. More time went to search for the car title that was hidden between them, which implied going through the coupons again. Finally, more than 90% of them went to the trash because they had expired or, after all, they weren’t that interesting.
From that moment, I decided to cut the number of coupons and correspondence I would save for later to at most one per week. I would also deal with important correspondence right away when it came in. If I had no time to go through the coupons, I would just trash’em all.
In the past two years (100+ weeks), I can remember only one important coupon that got through the mail, and that was for a discount that I could have obtained by just walking into the store and asking for it. This data point gives me more than 99% confidence that trashing all coupons for one given week is the right decision to take if I have no time to go through them.
With projects, companies tend to take the same approach that I took with coupons. “Put them in the backlog!” is the most common answer when an idea/project seems interesting, but it is not important or urgent enough to go above the line and be scoped and executed in the next few sprints. Moving a project to a backlog requires time to properly describe at least the idea, justification, and goal of the project. Extra time is needed to make sure that the backlog item is self contained so that it can be actioned in the future.
Every year, I am used to do spring cleaning on my teams’ project backlogs. One time, it took several weeks to go through the 471 uncategorized backlog items that my team had accumulated during two years. Invariably, during every spring cleaning the current projects are more important than the ones in the backlog. The projects in the backlog end up being removed from the backlog. This is a completely redundant task. At the end, somebody from our team had already taken the decision to de-prioritize them! Being not important or urgent enough are the main reasons why the projects were put in the backlog at first, right?
If you want to save your project for later, think twice if that decision is useful and scalable. Set a very high bar for a project to make it into the backlog. If you decide to create a backlog entry, put an expiration timestamp so that the project will not hang around forever. Give your team the time to define a proper structure of the backlog (categories, tags, expiration rules,…). Discuss the proposal with your team, get consensus, and stick to it. Make sure that the backlog structure and items are properly documented in the case that your team changes in the future. Taking harder decisions at the beginning will lead to a significant improvement in your technical debt down the road.
What is your approach? Are your coupons piling up as well?