No invisible work - put everything in your backlog
It’s important to make all work visible
Almost every team I’ve worked with has challenges early on capturing all their work in a single backlog. Teams tend to recognize the stories the Product Owner writes go in the backlog but often forget other categories of work that should end up as stories and be included in their backlog.
Don’t forget to consider including these categories of work
- Unplanned production support – When severe bugs are found in production it’s expected that teams drop what they’re doing and fix the situation. Saying “wait until next sprint” is just not an option. These defects should be written up in the agile tool and included in the sprint backlog. They can be sized relative to other backlog items and if needed the product owner should remove current commitments (pushing them to a later sprint) to make room for this work.
- Training – Is a team member going to be out for several days at a training event? You should consider adding a story for this to make sure you discuss during sprint planning and adjust your commitment based on the potential impact. There are good arguments to add points for a story like this and equally good arguments to not add points. In the end whatever works best for the team is the way to go, the key here is to make sure you have a conversation and no one is caught by surprise.
- Small tasks from leadership – It’s hard to say “no” when a manager contacts you asking for a particular task to be done. These may be large taking a few days or they may be small only taking a few hours. Either way it’s the responsibility of the team member to let their product owner know and make this work visible. If tradeoffs need to be made to absorb this work the PO should be allowed to make those tradeoffs, not the team members. If you get one of these requests bring it up with the PO as quickly as possible and determine the appropriate next steps either adding it to the backlog or deferring work until they have a chance to connect with the requestor
- Irregular long meetings – You don’t have to include every single meeting in a backlog, this would require a large number of stories for most teams. Usually you’ll find over the course of two weeks the amount of time spent in meetings or doing other administrative tasks is relatively consistent. If that’s the case these will just be a normal “overhead” for the team and don’t need stories. However occasionally there are long irregular meetings that team members have to attend, perhaps a special offsite planning for the testing team, or maybe discovery work for a new product that will be initiating development in the coming weeks. These irregular long meetings should be included in the backlog and discussed during sprint planning. Anything that would take a team member out for a ½ day or more should be highlighted so the team can decide if they want to allocate points to that effort or not.
- Refactors/Technical debt – Often when developing you may find sections of the codebase that need refactoring or perhaps features are launched in an MVP fashion and need to be refined so they are more maintainable long term. I personally prefer to create stories for this work to ensure 1) the time this robs from other work is highlighted and prioritization decisions can be made in an appropriate fashion 2) As these stories go through the team’s storyboard the team can ensure they receive the appropriate amount of testing (automated or manual) to ensure any refactors don’t create unexpected defects.
Why does this matter?
Workitems that go around the process often create a “death by a thousand cuts” situation. These activities take time, maybe not much individually but added together and considering the context switching they introduce it’s often surprising how much capacity they rob from a team. A team has a limited amount of capacity and it’s imperative they work on the highest priority items. Having every possible work item on one and only one backlog will allow for better prioritization and ultimately help the team get clarity on what can and can’t be done allowing them to meet their commitments without consistently working overtime. This practice is critical to ensuring the team is transparent and predictable.