How to organise boards and move a task/project between teams working on different stacks?

[Damien_R]

Intro

I'm looking for advice about how to handle this situation as we've been moving from issue management in Bitbucket to project management in Jira very recently.

We're developing a SaaS platform made of interactive modules made of Canvas (Board 1) then integrated to Angular for the front-end (Board 2) and then plugged to a self-service back-office the end user and the API (Board 3).

The current setup

(maybe not ideal - but matching our workflow)

• Board 1 - for Canvas Plugins development (stack: Typescript, Pixi)
• Board 2 - for front-end Angular integration (stack: Typescript, Angular)
• Board 3 - for back-end PHP and API integration (stack: PHP, Symfony)

Let's say each board is a kanban with: Backlog / Dev / Testing / Done 

Use case

Creating an interactive mini-game module.

1. The mini-game concept is first created in Board 1,
2. then integrated to the Angular interactive wrapper in Board 2,
3. then integrated to the Symfony back-end to make it available to the end user in the back-office and API in Board 3

The challenges

• We've different teams working on the different boards as they are different technology stacks.
• Each team/board may want to make a release version at the end of each board.
  • The developer of Board 1 wants to have his drag&drop module released in v1.0
  • The developer of Board 2 wants to then integrate the module to his v2.7 of the Angular app
  • The developer of Board 3 wants to then integrate the module and Angular front-end to his v6.5 of the SaaS platform
• From Board 1 to Board 3, the project remains the same, and the boards are just stages of the project that needs to be separated as they are different teams and stacks.
• An epic/story/task (not sure which one is the best) should be able to flow from Board 1, to Board 2, to Board 3 for the project to be completed
• At every stage of every boards, informations are added to the project, so it would be difficult to call a task "Done" in Board 2, when some information will be needed in Board 3. So it means the release of Board 2 won't contain the tasks that have been done, as they need to be transferred to Board 3.

The questions

1. How do you transfer tasks and informations from one team to the other, but still allowing them to complete tasks and mark them as "done"? Or is it just not required to mark something as "Done" when you make a release in an intermediate board?
2. Is the current boards setup right?
3. Is it good practice to move epics/stories/tasks from one board to the other?
4. If the Board 2 team wants to pass instructions to the Board 3 team, is it via a new epic/story/task? Or is it just as part of the initial ticket?
5. How do you handle releases of each stack if tickets are flowing across boards without being marked as "done"?

I would be available to discuss all this as I can't find any resources on that particular topic and structure.

Thanks in advance for your help :)

I'm also available for a quick chat on any communication channel that would suit you!

# Jan 4th, 2021 UPDATE

Here is some work in progress:

This allows me to have some overlapping columns (the "ready for...") so tickets when done are showing in the next board. But I've got the feeling they are losing some functionalities.

For example, let's take a PLU story that will become READY FOR API, the story will then show in the API board, so can be moved to the next columns/status. But when the PLU story gets to API > IN PROGRESS things like the API components aren't available to be linked to the PLU story. Which makes sense as the PLU story is related to the PLU components.

But this means that you can't really move a story/tasks...etc from one board to the other.

I also wonder if the status naming and structure above is right, or just too complicated as we repeat all statuses in a all boards with differents names...

Any insight would be much appreciated :)

[Damien_R · Accepted solution]

Happy new year everyone!

Some progress where I would welcome feedback from anyone!! :)

@Bill Sheboy do you reckon this would be the right workflow to move tickets from boards to boards?

This allows me to have some overlapping columns (the "ready for...") so tickets when done are showing in the next board. But I've got the feeling they are losing some functionalities.

For example, let's take a PLU story that will become READY FOR API, the story will then show in the API board, so can be moved to the next columns/status. But when the PLU story gets to API > IN PROGRESS things like the API components aren't available to be linked to the PLU story. Which makes sense as the PLU story is related to the PLU components.

But this means that you can't really move a story/tasks...etc from one board to the other.

I also wonder if the status naming and structure above is right, or just too complicated as we repeat all statuses in a all boards with differents names...

Any insight would be much appreciated :)

[Bill Sheboy]

Hi @Damien_R  Happy New Year!

First off, what works for your teams may not work for others, so there is no "best answer": only something that is better until you learn a another way toimprove.  If your approach is working, use it for a while, learn, and then decide what to try next to help.

With that in mind, consider why you are moving things between boards and what are the consequences of that need.

For your example, there is a PLU work item, which completes, and then is moved for continuing work on another board (API).  The PLU team loses visbility to how their workflow is doing... it looks like work starts and never finishes...it just vanishes.

Also in your workflow, you have status values which represent two ideas: the team doing the work and the progress.  (e.g. "PLU > In Progress")

One thing that might help is to consider if the items moving between boards are individually releasable or sub-items to finish a releasble item.  When PLU can do and "release" a work item, perhaps it should remain on their board, and the completion of it automatically clone to create any relevant next-step items, such as for API.  Then the status value names could be simplified to reflect a step, and the board provides the context. (e.g. "In Progress" on the PLU board)  To make that work you could use a value in the story such as Component or Labels to reflect impacted teams, such as: PLU, API, etc.

It this seems of interest, please take a look at the automation rule documentation:

https://support.atlassian.com/jira-software-cloud/docs/automate-your-jira-cloud-processes-and-workflows/

https://www.atlassian.com/software/jira/automation-template-library#/label/all/1453

Best regards,

Bill

[Damien_R]

Automation is the way foward!

I ended up cloning automatically the tickets that need to move from one board to the other.

Thanks for your help :)

[Bill Sheboy]

You are welcome, and I am glad you hear you got it working.  Please consider marking this question as answered; that will help others in the community find solutions to similar problems faster.  Thanks!

__Bill

[Bill Sheboy]

Hi @Damien_R 

Thanks for the details of the situation leading to your questions.  First thing: for questions like how to organize your work there is no "best answer".  What works for your team may not work for another, and how to "fit" your workflow into Jira may be different as well.

(1) How do you transfer tasks and informations from one team to the other, but still allowing them to complete tasks and mark them as "done"? Or is it just not required to mark something as "Done" when you make a release in an intermediate board?

• What you have described is three different release pipelines contributing to one value stream.  As the stacks release separately it may make sense to keep them separate.  Other teams might merge those into one workflow, reducing the need for transferring/handing off tasks.
• If you keep them separate, let work items finish when done in their pipeline.  You may manually create transition items/information, or use automation rules to create those automagically.

(2) Is the current boards setup right?

• You and teams probably won't know that until you use them for a while.  If they look like a good starting point, try them, pay attention, and pause periodically to decide what and how to improve.  Please consider each change as an experiment and forecast how you think things will improve.  That will give you insight the next time you pause to consider changes.

(3) Is it good practice to move epics/stories/tasks from one board to the other?

• Why do you need to do that move?
• If you are considering a parent item to span all release piplelines (e.g. Feature), maybe you need a fourth board (or dashboard) which can roll-up the progress on items spanning all boards.

(4) If the Board 2 team wants to pass instructions to the Board 3 team, is it via a new epic/story/task? Or is it just as part of the initial ticket?

• If one team needs to pass ideas to another, you could have them discuss (intake) the requests with the partner team.  Or, just put the items in their backlog for the partner team to "pull" when they have capacity.
• Please see my earlier responses about 3 versus 1 board idea and creating new work items.

(5) How do you handle releases of each stack if tickets are flowing across boards without being marked as "done"?

• Again, this is a discussion with your teams.  With three release pipelines, having three boards makes sense.
• One alternative is three technology "phases" on one board: discovery (canvas), FE, and BE.  With some work items never touching some steps/columns on the board.  This solves some challenges and creates others.
• A key consideration to help is work in progress (WIP).  If you expect to minimize WIP, working on only as many things as the entire flow can support, having everything in one location improves visibility to see challenges before they impact all the teams.

Once you decide how to proceed, please consider posting back here what you are trying.  Thanks!

Best regards,

Bill

[Damien_R]

Hi Bill, thanks for your insight! Very helpful and confirming my thoughts.

We went for this approach for now: https://community.atlassian.com/t5/Jira-Software-questions/Share-one-issue-quot-ticket-quot-across-multiple-projects-and/qaq-p/407534#M10014

as it makes sense in our workflow :)

Thanks!