Should you include non-development tasks in your Scrum backlog?
We're having trouble incorporating certain types of tasks into our product and sprint backlogs:
- Meetings with clients
- Training and knowledge-sharing
- Administrative tasks
Some of these aren't directly related to the project, so it's easy to put them aside and refer to them as administrative overhead (thereby reducing the doable story points in a sprint).
Some tasks, however (usually client meetings) are recurring or very frequent. How should these be handled? They don't usually directly relate to any particular user story, but they're vital for the project.
Answer
In my opinion, "tasks" don't really belong to the Product Backlog, Product Backlog Items (PBI) should be used for things that are visible to the end users - or mandatory to achieve such items - and expressed in a way that demonstrate their business value.
Recurrent events like meetings, administrative tasks, etc don't really match this definition of a PBI and I wouldn't include them at the Product Backlog level. Actually, I don't see the point of tracking them at all (it sounds like useless overhead i.e. typically waste) and I would thus simply include them in the overall velocity. It just works.
Non recurring events, like a special meeting, R&D, exploration, etc don't really belong to the PB neither (how should a PO value them and prioritize them??) and I prefer to include their "cost" in the estimation of the related PBI. And when the item gets picked, we create a corresponding task in the Sprint Backlog, with a timeboxed estimation.
And we handle trainings like holidays. If a team member go to some training, it affects the team member allocation (e.g. 90%) and thus the overall team capacity calculated at the beginning of a Sprint. And we pick up less items.