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?

[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.

[sclowes]

We're actually trying to make the process easier, not harder. Indeed you do try to reduce sprint scope if necessary but the goal is to complete everything you commited to for the sprint right? It should be unusual that items are left over. Understood that bugs and other items might fall out, but they will simply go back to the top of the backlog ready for the next sprint or to be ranked lower?

We are not forcing you to do anything, you can remove items from sprints if you wish. You could even bulk edit the issues to remove the value in the sprint field if you really wished to (though we wouldn't recomment it). The easiest route for you use case is to simply leave the items in the sprint then they will be put back at the top of the backlog ready for replanning when the sprint is closed.

Thanks,
Shaun

[sclowes]

I'm not sure how it's easier to achieve in the classic boards other than the fact that you can drag and drop rather than click on the issue, click menu, 'Remove from Sprint'.

In any case, please feel free to continue using the classic boards if they're more suitable for your needs.

Thanks,
Shaun

[Jon Palmer]

I wouldn't consder it unusual. We typically go into a sprint with a set of stories and a collection of bugs. We spend real time trying to make the stories fit the capacity of the sprint but it isn't efficient to estimate all the bugs we just know we will get to some, maybe all, and move some out if the feature development consumes all the sprint.

leaving the unfinished tasks in the sprint so that they roll over isn't viable either. We want to use the Task board to understand what is left in the sprint. Having identified issues that can slip we want to move them out so that we can focus on what's left.

The workflow I describe is a) common and b) easy to achieve in the Classic board where 'Sprints' really revolve around Versions. Moving an item out just means assigning it to a new version. The fact that the new Rapid board does not support this workflow (and the fact that Springs/Versions are now confused and I can only assign Sprints to tickets by drag and drop or the database id of the sprint (obtuse at best) makes the new Rapid Board unusable for us.

[Jon Palmer]

I the Classic board the 'Sprint' is based on the version. Given that I can move an item out of a sprint and into another by changing the version or into the backlog by removing the version entirely. There is no such feature in the new Rapid Board.