best practices for unscheduled stories in a sprint

Hi, what are your best practices for planning and reporting on unscheduled work. Some questions we're hitting on how to setup are:

Do you create a story as a place holder for them, since they regularly come up?

If so, we want to move the bug ticket into the sprint, estimate and log hours against it. So now we have 2 tickets to maintain. And no, we don't want to make the bug a sub-task.

At the end of the sprint how do you quickly sum up hours logged for those tickets?

1 answer

1 accepted

I'm not 100% sure what type of work you're referring to when you say 'unscheduled work'. If you provide more detail I could probably provide a better answer.

If it's a new requirement that we had not noticed before, we just add a new story to the backlog.

If it's a bug we put the bug in to the sprint. We don't estimate bugs (since they don't deliver customer value) so that's not an issue for us but you could if you wanted to. We also don't track hours but if you wanted to track hours you could do that with a time tracking enabled board (tracking is separate from estimation so you can track without estimating). The burndown chart will then show hours logged against the bugs.


Hi Shaun, thanks for the reply.

Maybe 'unscheduled work' isn't the best wording. I'm talking about work that isn't explictly product related. It includes a P1 bug, that could take a whole day to solve, or sending out half the team to a recuriting event. We do use the time tracking option.

Put it another way, do you plan and allocate hours for all types of tasks?

As for the burndown chart feature set, we do see hours logged/and remaining for tickets. But its not easy to filter types of tickets. I need to either search for the ticket number, or find the bug tickets, then find and add the hours up. What would be super helpful is having quick filters available in "report" mode. Then I can filter for bugs and see the hours calculated.

On the more academic side, can you explain "We don't estimate bugs (since they don't deliver customer value)". Don't you need to first estimate it to see if its worth injecting into your sprint. What if its a customer facing bug?

thanks and look forward to meeting you at the Summit again.


The GreenHopper team doesn't use hours at all, but we do estimate with story points. We just don't apply estimates to bugs because they represent 'overhead'... they're usually a side effect of a story done previously (which had a a story point estimate). We typically don't use the effort involved in a bug to decide if it's going in to a sprint, if it's important we put it in with the realization that it might push out a story. That's OK because in the end the velocity will stabilize at the number of story points the team can complete even if we have unexpected work in the sprint. I've written a bit more about this on a different answers post.

You're right that it's a bit painful to filter down to specific issues in the burndown. We'd like to implement a 'Refine' option for the burndown in the future, but for now you could copy the whole board and change the filter to only include bugs, this board's burndown will still show the sprints but will only see bugs.


Suggest an answer

Log in or Sign up to answer
Community showcase
Published Thursday in Summit

Find a your Summit 2019 Buddy!

Can you believe there's less than one month until Summit 2019? It's time to start planning your agendas, not to mention packing ... In the meantime, introduce yourselves on this thread so that you ...

216 views 14 6
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you