Should you include non-development tasks in your Scrum backlog? [closed]

Question

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 1

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.

Answer 2

Task is not related to product backlog. Task is related to sprint backlog. Activities you described are not tasks.

When we plan our next sprint we always reduce planned capacity by all holidays and trainings. We also reduce capacity by "administrative overhead". In our case administrative overhead is usually 1MD per team member per week. This overhead is for meetings and possilbe assistance in maintainance on already deployed projects.

Edit:

I think you should never create tasks for meetings, presentations, etc. in your spring backlog. Why? Because each task has some estimation wich affects current sprint. During sprint tasks are completed within real time and based on that burndown chart shows team progress in delivering customer value. What value will customer receive from meeting? Moreover such task is probably not related to concrete user story so what progress will be visible in product burndown chart? How you decide how many user stories should be taken for the next sprint when you have to count with value not included in their complexity (story points)?

Adding such dummy tasks (tasks with no added value) to your sprint backlog will also affect your velocity. It will look like each story point costs more than in reality because meetings time will be included in real work.

What type of meetings do you want to add to your sprint backlog? SCRUM needs only few meetings - daily meeting, planning meeting, review meeting, retrospective meeting and in larger project SCRUM of SCRUM. Daily meeting is so short that it doesn't have to be included in planning. Planning meeting, review meeting and retrospective meeting don't have to be included in sprint. SCRUM of SCRUM is specific and it doesn't affect whole team - can be reduced from planned capacity of attending members. No more meetings are needed. Most important: Communication needed for completing task is part of task estimate.

If you need other meetings simply reduce your capacity. If the customer, management or Product owner complain about small capacity simply explain them that it is because of non standard administrative or bureaucracy overhead.