How best to record tasks that are not part of the deliverable?

[Nick van der Net]

Hello community,

In our sprint backlog, I've included stories that only contribute towards the delivery of the product. We're using story point estimation. Because I have heard that scrum sprints should only detail cards that directly contribute to the deliverables (in our case, we're an Apps Migration project)

But my team clearly spends time on other tasks - for example: writing a test plan, writing an architecture document, etc.

How should I record these items and the associated time we spend on them?

Also, sometimes my developers are taken out of the sprint to do work on other BAU tasks as a matter of priority. It's always last minute. What's the best way to deal with this?

Thank you so much!

[Ash Pitt · Accepted solution]

Hey @Nick van der Net 

Plenty of options to consider, no hard and fast solution.

RE: How should I record these items and the associated time we spend on them?

Determine if you are using story points OR time.

In my opinion, if you are using story points, then that's your measure. The points are meant to take away from recording time etc. 

For example, Joe can completes 5 points in sprint 1, 8 points in sprint 2, 5 points in sprint 3 - you start to get a feel for Joe's capacity and it doesn't relate to time.

Using both will cause confusion and add more admin, which takes away from the work being delivered.

Read more about that here https://www.atlassian.com/agile/project-management/estimation

Re: Other tasks like test plan, architecture document, etc. 

1. Option 1 Use the task JIRA type card, record points separately if you need to.
2. Option 2 Roll up the effort in the estimate and use the sub-task function. For example if a dev is building a foo, it may be 3 points on it's own.

However if the foo needs to be delivered with a test plan, then that may increase the foo to a 5, and the dev could add a sub-task to track the test plan as part of the foo.

RE: developers are taken out of the sprint to do work on other BAU tasks

This will always be an issue. If BAU tasks are related to the project you are on, then you could add them (estimated) as tasks to your board. This will show a scope increase during the sprint. In which case you negotiate which tasks are removed so it's a burn down (not up or across) chart.

It could also mean that without interruptions, you know Joe can deliver 5 points in a sprint, but only delivers 3 due to constant interruptions - so you could say that Joe has the capacity to deliver 3 points per sprint.

Summary

Test out what works for your team, the next-gen project can give you some good flexibility to test out and see what works. I always go for the less administrative approach :)

[Iago Docando]

How is testing and the documentation not contributing to the deliverable? I would say that you should no doubt include those tasks in your sprint