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

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

On my last project we side stepped some activities in to our scrum board. They were not in the product backlog, but we invented them during our planning game.

The kind of activities we included was customer workshops, release activities, etc.

The reason we included them on our scrum board was to make it visible to anyone in the team what everyone else was doing, and in some cases also to assign the task to someone not in the middle of another critical task.

Answer 3

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.

Answer 4

Typical recurrent tasks are absorbed by the estimation/velocity. Things like the stand up meeting, normal developer's interactions, pauses, etc...

For others events that are not related to building the product, I prefer to remove that time from the developer's availability to have the correct capacity.

So the number of user stories that we can plan depend on, their estimation, the team velocity and of course the capacity

Answer 5

My opinion is if these tasks are not directly related to a feature, like training, you should not include them in your product backlog, but rather adjust the available time from developers and consequently the velocity of your iterations. It is not because you have for instance a 40 hours working week that you can expect people to work 40 hours on projects.