Does your Scrum Team have a compulsive hoarding disorder?

Everybody likes it tidy — nobody likes to tidy up. Here’s what you can do.

Published in

Serious Scrum

6 min readApr 4, 2019

What may be the worst part in organizing requirements with those modern digital helpers? The fact that disorder, overflow and being overwhelmed is invisible from the outside. Remember the time when cameras could take 36 pictures and album capacity was limited? I’m not saying this was paradise but at least we were forced to consider with which items we wanted to fill the void.

Today, digital storage is cheap, so we tend to continuously stuff User Stories, Tasks, Sagas, Defects and Test Sets into our Product Backlogs regardless of delivery capacity — a deceptive easiness that at some point in the future will inevitably lead to near-paralysis in the face of a seemingly unsurmountable pile of work. Ask yourself: are you regularly and consequently sorting, arranging and putting in order?

With physical things the effects of not following these principles are quite striking:

Though not that obvious, the impact of overloaded collaborative systems to people and products are likely the same.

What psychologists say

Compulsive hoarding (CHD) is a problem characterized by collecting and failing to discard excessive amounts of collected items. Without the dysfunction some things would simply be considered worthless and discarded or thrown away regularly. But people affected are no longer able to distinguish between important and not important or usable and not usable.

Often to some extent they understand their behavior is irrational but they are not able to act accordingly. Mostly they even have precise ideas on what to do with their amassed belongings but cannot bring themselves into actionable plans anymore. Effectively, they have difficulties setting priorities and steering their actions according to their own goals. In particular bringing plans to life is nearly impossible for them.

CHD is considered as similar to the attention deficit hyperactive syndrome (ADHS): a disturbance of the so-called „executive functions“, a set of processes that are necessary for the cognitive control of behavior — selecting and successfully monitoring behaviors that facilitate the attainment of chosen goals.

Sounds familiar?

We may not need hazmat suits when dealing with literally thousands of entries in Jira (or any other collaborative software), but we’ve experienced that the simple act of deciding which of their requirements to keep and which to throw out makes many people incredibly anxious: they worry that they will make the wrong choice and fear discarding or wasting anything that could prove useful one day. To avoid that anxiety, they often do nothing, allowing stuff to pile up even more. They also refuse to throw something out because they anticipate the blame that will follow. Further contributing to the whole mess is that for efficiency reasons people seldom take it upon them to find a specific requirement hidden in the storage. Instead they add it a third or fourth time, just for the sake of adding them.

In the past few years, decluttering has become fashionable in the real world, even an art form. Here are some inspirations on how to declutter your Product Backlog based on those.

Marie Kondo’s KonMari method or “Does your Product Backlog spark joy?”

While it may seem a bit esoteric at first glance, maybe even ridiculous, the method that made Marie Kondo famous and even gave her a show on Netflix actually is mostly about The Life-changing magic of tidying up: put every item in the middle of your room, ask yourself honestly if it provides value to you and if that is not the case then discard it. The main focus of Kondo is not the act of throwing away, it’s about coming to terms with the past. No User Story came by accident into the Product Backlog, every Task tells a story and with Kondo’s method we can finally close the book on that story. All Backlog Items kept will be then stored neatly in their respective places. Please note, this doesn’t have to be an operative Product Backlog but any storage where you can easily retrieve it.

Death Cleaning by Margareta Magnusson

A similar approach (if a bit more final), aptly named Death Cleaning by the swedish personal and business developer: instead of asking „does this User Story provide value to me“ she offers the ultimate thought: “if I leave the Team, do I want my successors having to deal with the stuff I left?” Only those Backlog Items where I can safely say YES will be kept. Feeling indifferent? Just discard it.

30 Days Cleanup Challenge

If you’re feeling uncomfortable getting rid of stuff then maybe the 30 Days Cleanup Challenge, as made popular by Joshua Fields Millburn and Ryan Nicodemus, is for you. Instead of trying to delete as much as you can you delete just one single item on the first day, two on the next day and so on. If you’re following this procedure closely after 30 days you will have gotten rid of 465 things.

Carefully select what to take back

The other way round is the Tabula Rasa approach, inspired by the film My Stuff. Move everything you currently have to a safe space and then each day you’re only allowed to choose only a couple of selected things and take them back. Give yourself a limit.

The Pareto Principle applied

Last not least, Japanese cleanup expert Hideki Yamashita observed that only 20% of the things we own account for 80% of the value. In her Dan-Sha-Ri book she recommends the 12–12–12 method. Throw away 12, transfer 12, return 12. Translated into Scrum with this approach you might want to delete 12 entries, transfer 12 to a separate space and return 12 to the original requester. At one go you will relieve your Product Backlog of 36 items.

When starting anew

In case you’re not inheriting an overblown Product Backlog but are in the comfortable situation of starting with a new Team and a clean and neat Product Backlog, apply a limit of entries you accept. 30 or 40 is suitable. I recommend being strict with changing requirements: whenever something comes in, something else has to leave.

From my own experience, the danger of hoarding in a Product Backlog is very real. In all cases this led to constant reprioritization and panic-fueled discussions due to lost oversight which in turns forced the teams to permanently adjust — and therefore came up with slower and slower delivery which made everybody unhappy.

One of the main duties of Product Owner is to say kindly ‘No’, it’s the role of the Scrum Master to help him doing so. When you do, please keep in mind that in the long run it’s not about working with the tools, it’s about changing habits.

Have you ever had to deal with a cluttered Product Backlog? Let me know about your experience.

Sources:

The Psychology behind hoarding on Psychology Today

Scientific American on research about hoarding