We have a board setup and this is working great but we need to take it a step further and add a new workflow which automatically assigns users working in a pipeline.
That way a single issue is added into the sprint and this allows all users to action the issue when they are supposed to. Going forward we might not ask the users to move to To Do, but set it so that if they move it to Done, then it automatically moves it to To Do with a new resolution etc.
So the question...how do I get this to happen? We can set the transition and have unique resolutions etc. but how do I add an IF condition to the transitions so that I can have multiple transitions which update the issue according to the resolution field?
I'm afraid this is a really bad design in JIRA terms. You really do not want to use Resolution like this - it should never have a value when it's in a to-do or in-progress column.
It actually sounds like your workflow is wrong - it should represent the actual process that you want to follow, which looks to me like to-do -> person 1 animates it -> person 2 sets it up -> done.
Agree! Just create new statuses, so that you can create this workflow (and columns in a board):
To Do > Animating > Configuring > Done
The Resolution field should be set just once, when everyone have finished doing what needs to be done.
Mind that JIRA considers as closed those issues that have a Resolution set, and that will affect the displayed data in many of its built-in tools/gadgets.
I actually agree with everyone, though the problem we have is trying to not over complicate things with multiple boards. Having a simple clear board is better as the team is multi disciplined and growing, so we don't want them to see a lot of columns which bear no relation to them.
Actually, this is a good case for multiple boards. Remember that the boards are a view of a pile of issues, and hence configurable separately. Rather than trying to build a terrible workflow that doesn't really match your process, just to get "one board", think about how to look at the process.
What I would do is:
This gives you a good overview, and team-centric views
Am I correct in saying that if we do this then these boards operate independently of each other? i.e. if the artist updates his kanban board then this doesn't update the spring board?
One of my concerns is that we don't segregate the team based on discipline, they actually work together as a mini team and so having different boards creates a sense of them being apart in tasks.
No, the boards are all views of the same underlying data. So a change in one board affects the others because their data changes.
It's not 100% dynamic, if that's what you're asking though. If you have one person looking at a board and moving stuff around, and another person on another machine is looking at a board. If person A moves an issue to a new column, it won't magically update the other person's board. If person B refreshes, or tries to do something with an issue that is now invalid, they'll be told about the change and the board will be updated. But because the changes are all to the underlying data, it remains valid (Note that this applies even if it's the same board they are looking at).
One thing I tend to recommend with multiple boards is to share all of them with all the teams - although your artists may work entirely in the artist Kanban board, make sure that they have access to the main Scrum board and the setup Kanban, so that they can see what others can see if they need to.
Ok. Let's simplify this a bit to begin with - forget the board for artists - whatever is wrong there is likely to be similar to the programmers board, so let's fix that first.
So, some basic questions:
On the scrum board, what is the board filter, and what status do you have for the columns of "to do" and "programmers in progress"?
On the Programmers board, what is the board filter, and the sub-filter, and what status do you have in the "to do" and "in progress" columns?
I realised very quickly after posting this that I had set up a scrum board which used a very similar project name to my test one. The problem was that I was referencing that one and not the test one where I had the issues :-0
Sorry about this, I thought I had deleted the comment before anyone noticed!
I have my own take on this but I really agree with Nic and Ignacio. I try to break this down all the time for customers so, simply put:
Mixing them will only cause headache. ALWAYS SET a resolution when you move to a green status. ALWAYS CLEAR the resolution when you leave a green status.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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