I am new to Atlassian Jira and have the following situation. At work, a group of less than five Project Engineers are involved in doing internal bidding proposals. Each bid consists of a specific set of about 13 steps which repeat for each bid.

Question

I am new to Atlassian JIRA and have the following situation. At work, a group of five project engineers (PE) are tasked with performing an internal bid process, each bid consisting 13 tasks. The same set of tasks are repeated every time a new bid is requested. Therefore, I would like to be able to “copy-paste” the tasks from a static list into Issues for new bids with just a change in assignee, date due and perhaps some new comments. Would Epics work for this? In addition, there may be several active bids due work at the same time. To expedite the process, I would like to allow the PEs to work on different tasks from different bids at the same time. This is similar to doing a family jig-saw puzzle where multiple family members work on assembling different portions of the puzzle at the same time. The reason I believe this will save time is because a PE might work on say 3 similar tasks at the same time for three distinct bids, and the other 2 PEs simultaneously work 2 other similar tasks. I am struggling to find a solution for this simple problem with JIRA. I like the Scrum board because it forces a time sprint to be completed, since the bids must also be completed in a specified time akin to a Sprint. However, a Scrum board restricts us on working on one Sprint at a time. If possible I would also like to see secondary board to show management who is working what issues task and when. This would facilitate managing ever changing priorities. If not too much to ask, I would also like to be able to organize the various bids on one board - could Components do the job? PLEASE HELP.

Ray Vigo · Answer

Thank you for your suggestions. I will continue trying different models until I find what works best for us, as Nic said.

I created a Kanban board based on (Epic) Issues I cloned for the Scrum Board. I organized swim lanes in terms of Assignees. I can clearly see who was doing what. I changed the Description of each Issue (tasks) to indicate the bid number it belong to. In a nut shell, I organized tasks from multiple bids in terms of Assignee via swim lanes.

Next, I will try your approach of assigning subtasks IF the different subtasks belonging to one bid can be displayed under different assignees across the swim lanes. Also I hope that each subtask provides a clear way of identifying which bid they belong to. For example, if I look at any subtask under any assignee, I could tell what task he or she is working on (i.e., task #7 of bid #1044 - In Progress). I could also try Mike’s suggestion of 13 columns, or better, 13 states in the workflow. Although, I foresee the assignees incorrectly dropping the issues into the wrong columns plus I would have to depart from the simplified workflow.

The 13 steps do follow a serial order, and most have to be worked sequentially, although some steps can be locally worked out of order, in parallel, or even skipped.

I agree that I should use the Kanban instead of the Scrum board since our bidding process contains enough versatility, exemptions and interruptions warranting a departure from the discipline that a true sprint process dictates.

Lastly, I really like all of Mike’s suggestions about creating filters to show near or overdue dead lines and to change the card colors to indicate time status. I will try all of this.

Thank you again for your time and help.

Mike Sorensen · Answer

If these 13 steps need to be performed serially and in order then you should have one "Bid" and it walks through 13 columns or states in the workflow.

If the 13 steps can be performed in parallel and out of a strict order then 13 sub-tasks would be my choice also. Someone when creating a Bid would need to either "clone" or create from scratch each of the sub-tasks from some template.

Kanban is the choice because your team doesn't follow a Sprint process, you are more asynchronous in the way the Bids start and finish.

For tracking time, I'd consider a few things:

* On a Kanboard, the issues show a dotted line that indicates how long the issue has been in this column. How stale is this specific issue or sub-task.

* On the Kanban board, create a few Quick Filters that set filters to only show Bids that are nearing their deadline or are late.

* You can setup Card Colors to be based on Queries. Then it could show red for late bids, green for on track and yellow for the danger zone.

Nic Brough -Adaptavist- · Answer

Epics could work, but I'd be more tempted to use issues/sub-tasks.

If you have a simple issue type of (say) "Bid", then you could use one of the "create subtask on transition" plugins to create the 13 sub-tasks every time someone creates a bid.  You've then got 13 distinct tasks to allocate to whoever needs to work on them (with multiple tasks in progress) and they're all held together under a bid.

You could create scrum board for each "sprint", but I think that's unweildy in your case, I don't think your process matches sprints closely enough to work.  I'd stick with Kanban boards and using the due dates to indicate deadlines.

And yes, components can help you with reporting.

You're not trying to do anything unusual here and Jira can handle it fine.  The difficulty is in doing it in a way that works best for you.