Hello,
Im new to Jira and trying to better understand how I should be managing a team that has two unique workflows. We are using sprints to manage our workload going forward because it works best with our current structure. What Im trying to figure out is the following
I have two unique workflows I need to support and don't really know how to set this up in Jira.
The thoughts that are going through my head are as follows.
Any feedback people have on this topic would be greatly apricated.
-Stephen
I agree with this.
You basically have two completely different processes where the first is a build process and the second is the strategic and financial process.
They should never be in one JIRA project because they do not have a 1-1 relation and you will have tasks that are strategic in size.
Two projects and two workflows: One where you plan and scope and one where you work.
I wouldn't do that. It sounds like it should be one project, but two workflows (which means two different issue types in that project)
If you have them in the same project, you can share things like components and versions, but still handle them with separate boards if you want to.
Two workflows still means that you need two boards or a shared set of statuses. There is no benefit in the visualization of work, and it just becomes confusing to have two completely different processes in one project.
Having the same components can be done anyway, but having in one project will mix operational and strategic components that will mean that neither team have a focused setup for their work.
You would not have a release for a strategic workflow. That will only feed operational tasks, which is the only place you would have releases.
An easy way to determine if you should have one project or two is to put everyone that works in both flows, including stakeholders, in the same room and see if everyone in that room need to know everything that is on the board.
If they do, then keep it in one project.
If they don't then use two projects.
The worst thing you can do is to force people to filter of change views to see what they need to see to focus on their work.
Clutter is never an optimal solution. Focus is.
>Two workflows still means that you need two boards or a shared set of statuses.
Why?
I can't see any reason to need two boards or total alignment of status across workflows. Could you explain why you think you need that?
Though that makes think further into how you might be thinking, leading to the question: What do you think a board is actually for? What do you think they represent?
Well, let's see:
The strategic workflow that generates the backlog items that is basically the ideation, finance and requirement processes:
Ideas>Analysis>Scoping>Ordering>Photographing>Send to Backlog
The Operative workflow that takes the work orders from backlog to making available to end user:
Backlog>ToDO>In Progress>IN Verification>Done
This would generate a board with 11 statuses. This also have two starting statuses and two complete statuses, one for each workflow.
An idea will most likely be of several sizes, meaning that an idea can generate a single story, or multiple. Each idea can also generate multiple dependencies and tasks to other projects that need to be mapped together.
When working with the strategic flow, many items will be shut down in analysis and scoping, some will get turned down in ordering and so on.
Like I said, if everyone in the project need to see everything, then keep it in one project and one board. If they don't then split it and then split it on project level so people don't have to filter or choose boards to do their work.
You can see my view on boards in my video here:
https://youtu.be/X2p4y2eTElE
Feel free to add your view if you disagree.
>This would generate a board with 11 statuses. This also have two starting statuses and two complete statuses, one for each workflow.
No, it does not.
It sounds like you have not actually created a board in Jira to cover this scenario. If you had, I would have expected you to have talked about the default columns you get for any new board - to-do, in-progress and done.
Try it out (setting this up won't affect your issues until you start to try to use it)
You now have a board with three columns, not eleven.
You can make it eleven if you want, but you'll find (if you have set the status categories correctly for each status) that the to-do and done columns are probably fine, and you'll want to create a few columns to cover all the options that have been grouped into the in-progress columns.
I am sorry, but what is the point of having multiple statuses if you just group them into the three types? Are you really moving issues between statuses that are all within the same column?!
That seems like a complete waste to me, and not to mention completely remove any value you get from visualizing in a board to begin with...
You can just as well skip the board then or just use the standard task flow.
On a technical point - there's a howling design flaw in Jira in that you can not move issues from a status in a column to another status in the same column. Much as I am an Atlassian fan-boy, I won't defend that failure.
> what is the point of having multiple statuses if you just group them into the three types?
Good question. It's not "just group them". Jira is, at its heart, an issue tracker. I'm not going to write an essay on its history (I think Scott or Mike should do that, not me) The boards are an additional function, not actually part of the issue tracking. A damn good way to represent and work with issues, but not the core.
The "new board" has no way of knowing how you might want to work, so it takes a guess at those three categories and expects us to refine it to what we want later.
"The "new board" has no way of knowing how you might want to work, so it takes a guess at those three categories and expects us to refine it to what we want later."
Yes, because the workflow can be open-ended, so there is no way to know the flow. That does not mean anyone should use the board that way :)
The fact that you can't move things within the same column is by design. The reason is that the Kanban is a visual representation of progress. This is also why Jira have workflows and not just checkboxes for completion like Asana for example.
I tend to design Jira using fetch and release and areas of responsibilities to define the workflows. That way I allow any ritual within the different processes since they only have a waiting and an active status.
To me this sounds that it could be best modelled with 2 different issue types. (If there are other differences, not only the statuses, but for example fields, between the two "kinds", then that also encourages using two issue types.)
Then you can associate a different workflow with each issue type.
(You can use the two issue types within the same, or in 2 separate projects, that freedom is not lost with this approach.)
Thanks for the feedback. I think your right @Aron Gombas _Midori_ @Janusch Rentenatus Both options seem solid. I will try to have the issues types determine the workflow for now. Then IF I hit a issue I know I can make a project that will provide more control.
Thanks for the brainstorming session guys!
I found having one project and with multiple boards works the best for me. I dont have to deal with task handoffs and reassociating data.
Recommended Learning For You
Level up your skills with Atlassian learning
Learning Path
Get started with Jira Software
New to Jira Software? These short, self-paced courses will teach you what you need to know to get up and running quickly.
The Beginner's Guide to Agile in Jira
Learn what agile, kanban, and scrum are and how agile works in Jira Software.
Realizing the Power of Jira Reporting and Dashboards
Use out-of-the box reporting and dashboard capabilities to view and assess progress and bottlenecks within projects.