nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

best practices for unscheduled stories in a sprint

BlueKai Support

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?

Accepted answers

sclowes

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.

Regards,
Shaun

All comments

sclowes

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.

Regards,
Shaun

BlueKai Support

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.

sclowes

Hi,

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.

Thanks,
Shaun

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira-software

best-practice