Tracking stories through different boards

[kim_theobald]

We have different tracks of working not working on the same stories in the same sprint, however we want to hand off a story to different boards and track their progress. For example, design has their own board and sprints and that will pass onto the Front End Development board backlog and they will move it into their sprints. Looking to see how best to manage this process and setup Jira to do this. 

[Earl McCutcheon]

Hello @kim_theobald ,

The layout can be rather simple or get as complex as needed to fit your exact needs as the customizability here can be quite vast, but a good approach to use scrum boards to track different phases would be to set up different issues as phases in the project for each part of the issue development cycle.  Then use automation Rules to create a new issue for the next phase for each team's board based on an issue type if you want different workflows for each portion of the work or a component to identify the issues current position in the cycle using the same workflow.

As a really basic example using the same workflow for three teams Design Team (DT), Development (DEV), and Testing (QA), and a workflow of "ToDo" > "InProgress" > "Done" > "Canceled", and flag each issue with a component "DT" for the initial step, "DEV" for stage 2, and "QA" for stage 3.

When you start the design phase the board for the design team can use a filter like:

Project = EXE and Component = "DT" order by rank asc

the issue will go through the workflow for design and can either be canceled if abandoning the work, or moved to "done" to move to the next stage.  And when moving the issue to done set up an automation rule with the transition being the trigger event to clone the issue but changing the component "DEV" for the next phase,  with something similar to the following example for our automation template library:

• https://www.atlassian.com/software/jira/automation-template-library/rules#/rule/1357222/26550314

Then repeat the steps for each phase.  This will allow you to maintain an independent scrum board for each of the teams and track the progress of each set of issues in each phase.

and if you want to dig further into some of these concepts I put together some of our blog post resources that take a deeper dive into related topics that may help further:

• https://www.atlassian.com/agile/design/collaborative-design-in-agile-teams-video
• https://www.atlassian.com/agile/software-development/qa-at-speed
• https://www.atlassian.com/agile/software-development
• https://www.atlassian.com/blog/inside-atlassian/jira-qa-process

Regards,
Earl

[kim_theobald]

Thanks Earl, it looks like this is a solution for automating the story to move to the next board within a single project correct?  This is a step that helps but we want to know how we create the stories so that you can run reports to see the status of all stories across the different boards in one project.  Would you use Epics for this? Labels? What is the best way to create the story setup? 

Thanks!

[Earl McCutcheon]

HI @kim_theobald ,

There are a few different things to look at.  The first being that agile reports are designed to give a detailed breakdown on a per sprint level (a micro view) and defining a sprint of sprints, so working the same issue across multiple sprints would lead to some confusion and data discrepancies, and additional macro view reporting would be best done in third party reporting toolsets that fit the exact needs for the overall scope of the report you are looking to build out:

• https://marketplace.atlassian.com/addons/app/jira/top-rated?hosting=cloud&query=report

Or you could build out custom reporting using data dumps to Excel or Google sheets using the free connector apps:

• Jira Cloud for Google Sheets (Official)
• Jira Cloud for Excel (official) 

Breaking down the project layout and the issues that you might face, if you want All teams to have a Scrum project to work out of, each team will need a unique set of issues, Design issues, development issues, and QA issues.  This is because the issues will remain open or be re-opened until the final portion of work is done, so if team one has issue-1 in their sprint and complete the issue and mark it as done, team 2 would then need to re-open the issue at the start work on the issue or team 1 would need to leave the issue open until the final stage is complete, this would then either reopen the issue on team 1's backlog or prevent team one from completing their sprints until the final team finishes their work on the final sprint as the issue remains open the whole time, as well as mess up the reporting.

An alternate approach would be to have a Scrumban or Kanplan configuration, where each team would work from a Kanban Board, and the project managers would work from a Scrum board tracking the overall progress of the entire scope,  this way the kanban boards will only include an issue at a certain stage of the process and the project manager would control the full sprint process, and the teams would be left with an individual scope of work.

Then there are the Roadmap views, which are designed around tracking project progress at a higher level, In Jira directly there is a basic Roadmaps feature as well as an Advanced Roadmaps feature that is part of Jira Premium, detailed more here:

• https://www.atlassian.com/software/jira/features/roadmaps?tab=basic
• https://www.atlassian.com/software/jira/features/roadmaps?tab=advanced

Beyond the Atlassian Roadmaps tools there are also a vast amount of third party roadmap tools available in the marketplace as well:

• https://marketplace.atlassian.com/addons/app/jira/top-rated?hosting=cloud&query=roadmap

Regards,
Earl