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

Moving tickets between sprints?

Jon Palmer

I would expect to be able to use the GreenHopper Rapid board to move tickets between sprints. However, I'm only able to remove tickets from a sprint and then drag them into a different sprint. This is really painful for bulk operations. Is there a better way?

Accepted answers

All comments

sclowes

Could you explain why you'd need to do this? At the end of the sprint any incomplete issues will automatically be moved back to the top of the backlog where they can be replanned in to the next sprint.

Thanks,
Shaun

Jon Palmer

Sure. We will plan a Sprint, lets call it Sprint 3. As we get closer to finishing the sprint we might identify tickets that are not going to make the final cut for Sprint 3 and we want to explicitly move them out to Sprint 4 (which we are begging to plan at some level) or the Backlog. Its very restricting that the drag and drop feature shouldn't allow moving between sprints or to the backlog.

sclowes

Understood, though I hope this doesn't happen often since it means the sprint is regularly overcommited.

We don't currently plan on changing this behaviour as it's not a common action and it's important that we prevent users accidentally dropping stories from sprints in Plan mode and causing scope change.

Thanks,
Shaun

Jon Palmer

That's very disappointing and I have to say surprising. I've worked in many agile organizations employing Scrum and in organizations where you keep the release date and reduce scope the sprint being 'overcommitted' is common. In fact if you include bugs and improvements in the scope of a sprint (which is certainly desirable from a tools point of view) then every sprint involves pushing some set of tickets out of the sprint.

Philisophically I think your product approach is flawed. We reasonable the tool should support a multitude of workflows and not force organizations to adopt a process that fits your very particular view of 'the right process'. That's a mistake and we're going to be forced to keep using the Classic boards until the rapid board is more flexible and its feature set expanded. I'm disappointed.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software