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.

Stott

I'm voting to close this question as off-topic because it is not about programming. – Glass

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.

Hematology

+1 for recurring tasks are part of the overall velocity, not tasks to be tracked for project progress. – Malinda

+1 They're not part of velocity, but it would be foolish not to account for them. It would make sense to have a 0-point task of X amount of hours for both the recurring and non-recurring things. This can give the project manager some solid metrics about how much the rest of the firm is causing his developers to be unproductive. – Eskimoaleut

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.

Pee

+1. Excellent answer. Specifically: Task is not related to product backlog. Task is related to sprint backlog & Communication needed for completing task is part of task estimate. – Muck

Answer 3

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.

Callis

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

Ammadas

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.

Weightlessness

Answer 6

If meetings or other non-development tasks are directly associated with achieving the objectives of the sprint\iteration\project then I have no problem including them the sprint backlog\iteration plan. If nothing else it helps to ensure that the tasks get done by raising their visibility.

Rosenkranz

Answer 7

If you don't include things that people need to do in your backlog, how would you propose to manage them?

Non-development initiatives take time, and they are just as important to delivering a quality product as dev and qa work.

You can choose to use a separate backlog for those items, or carry them in a separate project plan, but then you are working from two working backlogs, and sequencing and timing becomes an issue.

I typically force the teams to create stories for non-development activities like 'as a product manager, I need to produce a roadmap, or 'as a product manager, I need to setup technical workshops to review the backlog so that development teams can understand the features'.

it really depends on the situation, but if the backlog is THE central place to capture and manage work, why is it only Development and QA work that it gets used for?

Aposiopesis

Answer 8

There is no fix formula for deciding User Stories in Scrum. In my project, we pick and choose which work item should be converted to Stories. E.g. tasks like comparison of 2-3 IDE dev tools goes in a Backlog because it is directly related to development. But otherwise I plan for 5 hrs per day development activity for each team member so that they spend remaining hours in attending training, documentation, knowledge exchange, peer programming, etc. This works for me in justifying demo vs sprint velocity.

Thoroughbred

Answer 9

You can manage non-development tasks in a Trello board. These can be things like research activities or pulling data to be used for development. These don't belong in JIRA or Rally as they are not development tasks and do not have a story point estimation.

Aragon