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; } } }

Creating tickets in the active sprint? or in the backlog relating to active sprint?

Ahmed Alghamdi_6u0l4m

as you know, Jira treats any addition to tickets in the active sprints as scope creep.

we are a large team, of 3 vendors in different part of the world doing agile! during the active sprint, the team create many tickets such as clarifications, tasks and defects. but currently it all goes to the backlog, (as they don't always attach the impacted sprint to it)

i'm not sure if i should advice the team to always add the sprint (will be scope creep) or keep those out of sprint

the thing, when i do reports for progress based on sprints, they don't show, hmm what ya'll think?

Accepted answers

Nic Brough -Adaptavist-

It's generally better to let all new stuff go into the backlog, as that keeps your sprint reporting clean. Scope change for existing sprints is a pain and makes it hard to see what is happening, which makes your planning harder.

If you find you need to be drawing things into sprints a lot because of various pressures, consider shortening your sprint cycles, so that you can pull them in more quickly.

All comments

Nic Brough -Adaptavist-

If you find you need to be drawing things into sprints a lot because of various pressures, consider shortening your sprint cycles, so that you can pull them in more quickly.

Ahmed Alghamdi_6u0l4m

hmm an example, team A is developing story, they do integration testing and it fails, they raise a defect to team B in another country to fix their backend so they can integrate.

if we create that defect to the backlog, it would be hard to manage as it will not be at sight, but if added to active sprint, we will track it's progress and close it so team A can resume integration!?

Nic Brough -Adaptavist-

You could do that, which would force the team to deal with the new issue

But, it won't be estimated, so you'll have no way to plan for that to happen. Or, if you do increase the estimate, then your scope will change for the sprint, which also makes it much harder to plan reliably. If you're going to bring things into a sprint that increase the scope, then it may be better to reduce your estimates of what you can do in a sprint, and allow leeway for these things to creep in.

Welcome!

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

Quick Links

Find more posts tagged with

jira

agile

scrum

best-practice