If you and your development team are using a Kanban board then you are familiar with the term WIP limit. WIP is short for Work In Progress and the idea is that putting a limit on the amount of ongoing work will help the team focus on the most important work and getting more work items completed. The limits will also help with identifying bottlenecks in the work flow that needs to be addressed.
I think WIP limits are great. Personally I try to work on only one thing at the time as much as possible and minimize context switching. There is however one more limit that I would like to propose, the WIB limit. WIB is short for ’Work In the Backlog’ and the goal of the limit is to avoid having the number of items in your backlog growing out of control.
The backlog problem
In my experience, backlogs with 100 or even several hundred items in them are not unusual. As time goes by more and more items are added, at a faster pace than the development team can finish the items on top. This usually goes on until the product owner goes on a cleaning frenzy and drops the majority of the items. The cycle then starts over and the backlog continues to grow.
So why is this a problem? For once, if you get a request for a feature from the organization and your response is ”Sure! I am putting it in the backlog and we’ll work on it as soon as possible”, and you have 100 other items in the backlog with higher priority, you are pretty much lying to the organization that the feature will be developed…ever. And once people starts to realize that their items aren’t being worked on they will try to find all kinds of ways around your work process.
Second, trying to keep an overview of, and prioritize between, hundreds of items is just not realistic. The work effort required to keep them up to date and in correct priority order is just too big.
Third, there will be times when you start feeling guilty for having items just lingering in the backlog for months and months, but because they have been there for so long the notes written in them will be out of date or difficult to remember what they actually meant, meaning you have to start over with any work you put in to understanding requirements and write a good user story in the first place.
The WIB limit
I suggest putting a hard limit on the number of items in the backlog. There is no exact number that I believe works for all but somewhere in the range 15 – 20 items should be the limit. It should be possible to have a pretty good overview on 20 items and keeping them prioritized.
Once the WIB limit has been reached, no new items are added to the backlog until there is free space. Any requests to add new items are rejected, justified by that there just isn’t any room for new work items at this moment.
Now, there will be times when something really urgent pops up that needs to be put high up in the backlog. When this happens, and the WIB limit has already been reached, the item with the lowest priority must be dropped and the organization has to be informed that this happened. If the item put in is really top priority, then this must be accepted.
Note that introducing a WIB limit will not in any way reduce the number of work items being completed. Instead it will help with highlighting the current work load, make it more clear what items are prioritized and why, and keep development teams from making promises they can not keep.