Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,457,469
Community Members
 
Community Events
176
Community Groups

What is the best way to manage two types of content?

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.

  1. Production: Backlog>ToDO>In Progress>IN Verification>Done
  2. Generate Backlog: Ideas>Analysis>Scoping>Ordering>Photographing>Send to Backlog
    (Send to Backlog refers to the first workflow)

The thoughts that are going through my head are as follows.

  • Should this be done using new projects?
  • Should this be done making a new task type?
  • What is the more scalable solution?

Any feedback people have on this topic would be greatly apricated. 

-Stephen

3 comments

You can create two projects, each can have its own type, each can have different state transitions.

If you need it, you can define your own additional states differently in each project.

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)

  • I am assuming that you've set up the two workflows and applied them to two different issue types in the same project already
  • Create a filter for "stuff which I want to deal with in a Scrum or Kanban style", and save it with a helpful name.  "Project = XYZ" is good enough for this test, I'd leave out the bit we agree is a problem on "or label/customfield =".
  • Go into a company-managed project and create a new board (scrum or kanban)
  • Choose "create from filter", using your saved filter

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. 

Like Troy Anderson likes this

Thanks for the feedback. Many greetings. 

Comment

Log in or Sign up to comment