Hi there, in our Project Backlog, I have several "sprints" - our active sprint and several sprints that I use for organizing the stories, e.g. one sprint "up for grooming".
Is it possible to have a story, that is in the "To Do" column in the currently active sprint for more than a given period of time, let's say two weeks, to be automatically moved back to the "up for grooming" sprint?
How and where could I set this up?
Fallback would be some kind of flag or label that could be set.
Hi @Florian Eßer,
That is a very creative approach. But it feels like you are breaking more or less all the basic rules of scrum here (sorry!).
When you start a sprint, it is because you want to give your team a focused set of stories / tasks / bugs to work on for a limited period of time - in the books usually 2 weeks (but you are free of course to choose any other length).
This is the commitment of your team for the period to come. So if you say you want to automatically remove items that remain in there for too long, you are saying that potentially your sprint duration is potentially too long, or that you tend to overcommit. And then it seems to make more sense to look into adjusting the length of your sprints or the number of tasks you schedule into them.
Normally, when you complete your sprint, Jira will automatically ask you what you want to do with the incomplete issues in your sprint. So at that moment, you can perfectly decide if they should go back into the backlog (for grooming again) or into another sprint.
Obviously, I can't tell from your question if you aren't using sprints to tackle another way of organising your work. I've seen plenty of organisations use sprints for MVP's, for example. But for that case, Jira actually has fix versions (releases) in place.
Hey Walter, thanks a lot for your reply.
I am very well aware of the fact, that we do not use scrum (and - in my opinion for very good reasons). We use kind of a scrumban approach since we have varying amounts of dev capacity available.
Anyways, Jira is not only for scrum, so maybe there is a way to automate the issue :).
Absolutely, Florian. I totally agree on that. Having said that you may be better of using a Kanban board with a kanban backlog rather than a scrum board, with releases to manage the organisational part of the backlog.
Using sprints just adds the complexity that you need to explicitly start them at a given point in time. That still feels like the right moment to reflect on available capacity for the period to come and commit to an amount of work that aligns with that capacity and repeat the process. Even with flexible sprint length and no focus whatsoever on velocity and other ceremonies / practices you don't use.
If your process does not have this commitment moment at all, then using sprints at all may simply be not the right way to go about.
I don't want to keep you just hanging there with the feeling I'm not answering your question. I just think it's important to be solving the right problem.
So - if you do want to automate things here - in whatever way - it will be crucial to compare the sprint start date of your issues to the current date.
This question has quite a few useful pointers as how to reference the sprint start date.
Catch up with Atlassian Product Managers in our 2020 Demo Den round-up! From Advanced Roadmaps to Code in Jira to Next-Gen Workflows, check out the videos below to help up-level your work in the new ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events