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

Damovisa_77546 0
Viewed 8449

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.

scrum agile task project-management administration
9 Answers

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.

user_5898590

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.

user_19793910
Related