The biggest problem with ticket management systems like Jira is that they are too powerful. Having a backlog of 300+ items is no problem. Whenever some new topic is raised we always have an answer — “let’s create a ticket”. And then forget about it.
With 300+ items on the backlog majority of the tickets will stay there forever or until we throw the whole list away and start over again. This outcome does not differ no matter how much time we have invested into “backlog grooming sessions”.
I’m a big fan of the approach that Basecamp is using where they have no product backlog at all. If something is important we either need to act on it immediately or it will remind us again. During planning ideas should be owned/brought up by the people in the team not by some anonymous issue tracking tool. At TransferWise each team does a quarterly plan that usually consists of 3–4 problems to solve. No ticketing tool is needed on that level. Still there are smaller topics that come up outside the quarterly planning cycle that can grow in the backlog like weed.
Don’t treat your backlog as your attic where you can dump old stuff you really don’t need but are too lazy to throw away. Instead treat it as your upcoming work queue.
Following are the rules that I use to keep backlog size under control:
- never add new item to backlog unless:
a) team will work on it this or next week
b) it’s a bug (ideally should be fixed within 1–2w as well)
- never have more than 10 items in the backlog queue
If there are more, move them under “Ideas”. “Ideas” is just another name for “Most probably will never get done” but psychologically it is much easier to just move things there than delete them. Some tools have dedicated support for this e.g. in Pivotal Tracker it’s called “Icebox”.
Obviously the exact number may vary depending on the size of the team. Idea is to have few enough so it does not require much effort to keep it clean. At the same time have many enough to avoid running out of things that can be picked up next.
- split the high level item into smaller tasks just before starting to work on it instead of doing it early on. Additional benefit is that this helps avoid context switching and forgetting some details we discovered during splitting.
P.S. Interested in working with us? We’re hiring! Check out our open Engineering roles here.