Table of Contents

Introduction

Never worked with Jira before? No problem. Please first read the Jira training Basics page.
In this chapter below the Jira setup for Information Systems project Jira-projects is explained.

Jira projects

Information Systems are Division is using the following Jira projects:

...

In a future state for 2023 only the Jira Projects in black text above will remain for Information Systems.

• Yamaha Applications Yamaha Applications Support Desk (SD) captures all requests from end-users, who experience difficulties with their day-to-day use of IT applications. These items are validated, then if valid resolved as soon as possible.
  
• Yamaha IS Projects (YIS) captures all work of (scrum) teams in the Agile Transformation. These processes are being streamlined to support scrum processes, and make Jira a tool for collaboration more than administration.
• B2C-Apps (B2C) captures  work for B2C /EPAM team(s) working with waterfall methodology. Processes are being streamlined with new Yamaha way of working. Epic, Story, Task, Spike, Bug, Defect are not created anymore in B2C but in YIS.
• Yamaha Portfolio Board (YPB) collects all Yamaha Portfolio Board (YPM) collects all ideas for IT initiatives, and validates the business case and expected rewards for implementing such initiatives before assigning work to development teams. It's very much about preparing work.
• Other Software delivery projects capture work for teams that have not yet joined the Agile Transformation .

In due time, Information Systems teams working in Jira Software projects will be onboarded to the YIS project, so this can become our mutually agreed way of working for Software delivery.

Any team joining will be coached through the (Agile) transition and will be able to provide input on unique ways of working that will need to be integrated. Together we will make it a success.

For now, these Information Systems projects will keep on using their current of way of working. With time and proper preparation, they will migrate into YIS. 

...

J-sox compliance

J-SOX requires Japanese companies to enhance internal control reporting and demonstrate the effectiveness of their internal controls. 

To be J-SOX compliant, Yamaha Motor Europe N.V. will need to demonstrate 4 primary security controls in a yearly audit:

• Secure Access Control Management. 
• Demonstrate a Resilient Cybersecurity Framework. 
• Demonstrate Data Backup Protocols. 
• Change Management.

For Information Systems Division Controls will be integrated in the Jira workflows:

• Secure Access Control Management: new user accounts must be registered and logged in Jira. Users manager need to be informed and included in the ticket.
• Secure Access Control Management: all user authorization changes for Business applications (Ympact, SYS2000, YLS) must be logged in Jira.
  Approval for new authorization(s) is required from IT management (division manager, department manager, team lead).
• Change management: approval (SQL's) by IT management (division manager, department manager, team lead)
• Change management: Role segregation for development and testing. Developer does not test their own developed code.
• Change management: Deployment approval request by IT management (division manager, department manager, team lead).
• Change management: Deployments can only be performed by authorized roles (division manager, department manager, Team lead, Product Owner, Delivery manager).
• Change management: Agile teams must met the organizations set Definition of Done. This is done via a checklist for issues moved to ready for Deployment.

Beforehand it is not known if a database correction or program change is required, to prevent delay in resolving reported requests the users manager is automatically added to the request (Jira issue/ticket).
YME and distributor users are directly synchronized in Jira with Active directory including users manager. The users manager is added via a automation after request creation. 
Active directory is maintained by Servicedesk.

Yamaha Applications Support Desk (SD)

In Yamaha Applications Support Desk all operational support (BAU- Business As Usual) requests are registered that relates to IT Application Issues/errors for existing functionality, data correction and authorization requests.

Users can create a new issue via the Yamaha Motor Europe support portal, via this portal you can go to the YME Information Systems Support Portal to submit a IT request.
Instructions of the portal forms can be found here: YME Information Systems Support Portal Guide

The Image Removed button should NOT be used for creation of a SD issue.

SD Issuetypes

Image RemovedIncident:  Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal will have Issue type Incident.

Image RemovedService Request:  Request for information, this issue type is currently not used anymore.

Image RemovedAudit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.

Image RemovedAuthorization request: Elevate user rights request used for Ympact to request YMXXITS1 access to have command line access and to operate in Ympact (Branch specific) Production environment.

Image RemovedRobotJob Change: Robot Job Change request used for Ympact Job scheduling

Image RemovedDeployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.

SD Issues overview

SD Specific Fields

SD mandatory fields have been highlighted in Yellow

Image Removed

• Type: Issue type
• Priority: By default issues are set to Medium
  Image Removed
  
• Solution group *: Drop down single select list to define which department will be working on the issue.
  Image Removed
• Team Yamaha: Label field, multi select, always starting with team# <team name> mandatory for non-agile teams to determine which team will be working on the issue.
  This field will be replaced with Yamaha Team.
  Image Removed
• Yamaha Team*: Drop down single select list to define which (agile) team will be working on the issue.
  Image Removed
  
• Application-Module:  Drop down single select list to indicate the involved Application-Module of the reported request (issue).
• Department: Department of the reporter of the issue.
• Company: Company of the reporter of the issue.
• Epic Link: Linked epic issue if a issue is related to a Project.
• SD Classification: Drop down single select list, by default for incoming issues set to Business as Usual (BAU)
  Image Removed
  
• Status: Workflow status
• Resolution: Resolution can be set when a issue will be closed.

...

Image Removed

• Request Type: Customer portal request type
• Customer status: Status visible in the Customer portal. This does not always corresponds directly with the issue workflow status.
• Channel: Portal or e-mail request
• View customer request: link directly to the Customer portal request. This link can be shared if a customer need to access a specific issue.

SD Workflow(s)

Image Removed

Image Removed

If a (bug) fix for a application is required the Bugfix transition can be used to trigger a issue being created in a Development project.

Change Advisory Board (CAB)

Change advisory Board (CAB) workflow is used for approval of fixes and creation of a functional/technical conceptional design document.

This project will be phased out as Bugfix issues can be created in the software delivery projects directly via the SD Workflow.
Changes, improvements should be requested via creation of a Project  by a YME Portfolio Board Manager via the Jira training for Information Systems.

CAB Issue types

One of the two following conditions must be met to create a CAB issue.

1. Image RemovedBug: Bugfix to deliver a functional/technical solution for the original SD issue. SD issue remains open until the fix has been applied.
2. Image RemovedStory: Non-bugfix for internal improvement, prevent (recurring) issues for the future. SD issue can be closed, user will be informed that current issue is fixed but there will still be worked on in the background to prevent from happening again or improvements.

...

CAB Workflow

Image Removed

Function design (FD) and Technical design (TD) documents can be found in Confluence under space  Functional Conceptional Designs.
At the main page instructions can be found how a Functional/Technical Conceptional Design document can be created (via standardized template).
Image Removed

Yamaha Portfolio Board (YPM)

Yamaha Portfolio Board is a collection of programs and projects that together should execute the strategy of the organization and contribute to its goals and objectives.
Enhancements, improvements and new functionality requests are raised via the Yamaha Portfolio Board (YPM) and can only be raised by YME Portfolio managers, these are the Directors and Division managers.
Functional Design (FD) and Technical Design (TD) activities and approvals are done in the Yamaha Portfolio Board (so no longer CAB).
Planning activities for YPM is done in Jira via Big Picture, by the Project Owner.

All project related documentation can be found under Confluence space Yamaha Portfolio Board. In here you can find Procedures, Training material, report outs, processes etc. 

...

• and will be phased out when moved to YIS.

• Yamaha Motor next Stage Project (EUYNS) Yamaha Motor Next Stage Projects (YNS) has been setup as supporting platform to check the progress between YMC and PwC at the same time in the YNS project. 
  Per 01 Jan 2024 this project will be replaced by a new structure Yamaha Motor Next Stage (YNSEU) after the lead has been handled over to YME.

• Yamaha Motor Next Stage (YNSEU) captures the high level Project tracking for Yamaha Next Stage project EU rollout. 

In due time, Information Systems teams working in Jira Software projects will be onboarded to the YIS project, so this can become our mutually agreed way of working for Software delivery.
Any team joining will be coached through the (Agile) transition and will be able to provide input on unique ways of working that will need to be integrated. Together we will make it a success.
For now, these Information Systems projects will keep on using their current of way of working. With time and proper preparation, they will migrate into YIS. 

The Change Advisory Board (CAB) captured approval of fixes and creation of a functional/technical conceptional design document , this has been phased out completely as it has been covered by the Yamaha Portfolio Board and Jira Software project(s).

In paragraphs below you can find a short summary per project and links to the more detailed Jira-project documentation.

Hierarchy issue types used  in the projects by YME Information systems can be found on the following page: YME Jira Hierarchy

J-sox compliance

J-SOX requires Japanese companies to enhance internal control reporting and demonstrate the effectiveness of their internal controls. 

To be J-SOX compliant, Yamaha Motor Europe N.V. will need to demonstrate 4 primary security controls in a yearly audit:

• Secure Access Control Management. 
• Demonstrate a Resilient Cybersecurity Framework. 
• Demonstrate Data Backup Protocols. 
• Change Management.

For Information Systems Division Controls will be integrated in the Jira workflows:

• Secure Access Control Management: new user accounts must be registered and logged in Jira. Users manager need to be informed and included in the ticket.
• Secure Access Control Management: all user authorization changes for Business applications (Ympact, SYS2000, YLS) must be logged in Jira.
  Approval for new authorization(s) is required from IT management (division manager, department manager, team lead).
• Change management: approval (SQL's) by IT management (division manager, department manager, team lead)
• Change management: Role segregation for development and testing. Developer does not test their own developed code.
• Change management: Deployment approval request by IT management (division manager, department manager, team lead).
• Change management: Deployments can only be performed by authorized roles (division manager, department manager, Team lead, Product Owner, Delivery manager, Release manager, Servicedesk,).
• Change management: Agile teams must met the organizations set Definition of Done. This is done via a checklist for issues moved to ready for Deployment.

Beforehand it is not known if a database correction or program change is required, to prevent delay in resolving reported requests the users manager is automatically added to the request (Jira issue/ticket).
YME and distributor users are directly synchronized in Jira with Active directory including users manager. The users manager is added via a automation after request creation in the Yamaha Applications Support Desk (SD). 
Active directory is maintained by Servicedesk.

More information about J-Sox and the controls can be found on J-SOX Space - J-Sox process high level.

Yamaha Applications Support Desk (SD) 

Anchor
Yamaha Applications Support Desk (SD) Yamaha Applications Support Desk (SD)

In Yamaha Applications Support Desk all operational support (BAU- Business As Usual) requests are registered that relates to IT Application Issues/errors for existing functionality, data correction and authorization requests.

Users can create a new issue via the Yamaha Motor Europe support portal, via this portal you can go to the YME Information Systems Support Portal to submit a IT request.
Instructions of the portal forms can be found here: YME Information Systems Support Portal Guide

Note
The Image Added button should NOT be used for creation of a SD issue.

If a bugfix is required to deliver a functional/technical solution for the original SD issue a linked Bug and for B2C Incident can be created in a Software delivery project.

The SD issue remains open until the fix has been applied and is used to keep the reporter and participants informed or to collect information from the requester.

More detailed documentation for this project can be found under  Jira training for Yamaha Applications Support Desk (SD).

Yamaha Portfolio Board (YPB)

Anchor
Yamaha Portfolio Board (YPM) Yamaha Portfolio Board (YPM)

Before work is ready for development, any initiative (idea) for software development is first vetted by the portfolio management, to understand whether the proposal is of strategic value to YME.
Once it is agreed that the initiative should be implemented, a selection of what to do first is made based on business case, priority, and urgency. This way we ensure that time is spent on the most valuable topics.
In Jira these initiatives are created within Jira-Project Yamaha Portfolio Board (YPB). After a initiative is approved in the Yamaha Portfolio Board (YPB), development items for implementation will be created by the teams in a Jira Software Delivery Project.

Jira Training documentation can be found under: Jira training for Yamaha Portfolio Planning (YPB)

Software delivery projects

In due time, Information Systems teams working in Jira Software projects will be onboarded to the YIS project, so this can become our mutually agreed way of working for Software delivery.

Any team joining will be coached through the (Agile) transition and will be able to provide input on unique ways of working that will need to be integrated. Together we will make it a success.

For now, these Information Systems projects will keep on using their current of way of working. With time and proper preparation, they will migrate into YIS. 

Jira project B2C-Apps (B2C) will remain for B2C teams working with Waterfall methodology. For Software delivery Consumer train teams will work in YIS (Epic, Story, Task, Spike, Bug, Defect)  Processes are being streamlined with new Yamaha way of working.

Yamaha IS Projects (YIS)  

Anchor
Yamaha IS Projects (YIS) Yamaha IS Projects (YIS)

Project YIS is set up as a single space to allow Information Systems and Business to align on an Agile way of working, as part of the Agile Transformation.

Together we strive to arrive at a Jira configuration that is usable for all teams, supporting all YME Information Systems processes in a comprehensive, simplified manner.

Documentation can be found on the following page: Jira training for Yamaha IS Projects (YIS) 

B2C-Apps (B2C) 

Anchor
B2C-Apps (B2C) B2C-Apps (B2C)

Project B2C is set up as a single space for Consumer Train to work with a Waterfall methodology.

Together with EPAM and Yamaha teams we strive to arrive at a Jira configuration that is usable for B2C, supporting all YME Information Systems processes in a comprehensive, simplified manner.

Documentation can be found on the following page: Jira training for B2C-APPS (B2C)

Yamaha Motor next Stage Project (EUYNS) 

Anchor
Yamaha Motor next Stage Project (EUYNS) Yamaha Motor next Stage Project (EUYNS)

Yamaha Motor Next Stage Projects (YNS) has been setup as supporting platform to check the progress between YMC and PwC at the same time in the YNS project.
Only some Information Systems and Business users are having access to this project.

Documentation can be found on the following page: Jira training for Yamaha Motor Next Stage Project (EUYNS)

Yamaha Motor Next Stage (YNSEU)

Anchor
Yamaha Motor Next Stage (YNSEU) Yamaha Motor Next Stage (YNSEU)

YNSEU has been setup to track the high level planning for Yamaha Next Stage project EU rollout. 
By managing the Yamaha Motor Next Stage project in Jira the progress is visualized and can be used for managing the relationship of tasks across teams, the relationships between stakeholders can be strengthened and appropriate methods can be considered within the YNS project.
Only some Information Systems and Business users are having access to this project.

Documentation can be found on the following page: Jira training for Yamaha Motor Next Stage (YNSEU)

Issue assignment 

For all Jira-Projects used by Information Systems except for EUYNS the following issue assignment information applies.
If action from a Information Systems team is required or of it has been wrongly addressed some settings need to be changed to address it to the correct team/Train.
Visibility of issues in a queue/dashboard/board depends for all Information Systems Teams on the following 2 settings:

1. Solution group (all Projects used by Information Systems except YNSEU)
2. Yamaha Team or Yamaha Team(s)
   1. Multi select field Yamaha Team(s) field is used in YPM project and YNSEU
   2. Single select field Yamaha Team is used for all other Jira Projects and Issue types used by Information Systems Division.

Image Added Image Added

Overview Solution group and Yamaha Team / Yamaha Team(s)

Within Information Systems Division there are four Agile Release Trains

• Consumer Train 
• Business Train
• Enable/ Shared Services Train
• Data and Integration Train

The train is made up of multiple agile teams, an overview can be found on the following page: Team details - all trains

Incoming issue handling for Yamaha Application Support Desk (SD)

For all incoming SD issues the following field selections need to be checked if the correct one is selected, if not please adjust or add:

1. Adjust or add correct Yamaha Team
   After Changing Yamaha Team the Solution group will automatically be corrected via automation rule.
   
2. Adjust if not the correct SD Classification is selected
3. Adjust the Application-Module if wrongly selected
4. Check if request includes are requires information, if not ask customer to provide more information. 
5. An Issue can be allocated to a person when starting on the request/taking care of the request.
   When issue has been assigned before then only re-assign the issue.
   Re-opened issues also need to be re-assigned via the Re-assigned-comment button. 

Assigning an issue to different team

For moving a issue/ticket to a different train/team follow below procedure:

1. Field selection: 
   1. SD Project
      
      1. Select the Yamaha Team  corresponding to the Solution group as per above overview/ Team details - all trains.
         After changing Yamaha Team the Solution group will automatically be corrected via automation rule.
         
      2. Make sure the correct Application-Module is selected.an 
   2. Other projects but YPM Project, Programme and Epic: 
      1. Select the Yamaha Team  corresponding to the Solution group as per above overview/ Team details - all trains.
      2. Make sure the correct Application-Module is selected.
   3. YPM Project, Programme and Epic:
      1. Select the  Yamaha Team(s) corresponding to the Solution group as per above overview/ Team details - all trains.
      2. Make sure the correct Application-Module is selected.
2. Remove yourself as assignee
   1. If you still want to track the issue to receive notifications, include yourself as Watcher.
   2. If you still need to be involved actively add yourself as requested participant
3. Add a comment to the issue with your request toward the Yamaha Team, in case of temporary assignment to other team request to reassign the issue back to your Solution group/Yamaha team/ Yamaha Team(s).

The persons who are handling the queues from the train/team will take further care of the ticket and move them to the second line if needed.

Add-ons used by Information Systems

• Agile Tools & Filters for Jira Software
• Checklist for example used for Custom field DOD in Software projects.
• Doublecheck for Jira Service Management 
• Eazy BI
• Jenkins Integration for Jira Server and Data Center
• ProForma: Forms for Jira
• Status Time Free
• Timesheet Reports and Gadgets
  This addon is used by Information Systems, Business train to log hours spend on Projects, issues. When hours are logged there is more insight in the velocity of teams and specifically projects.
  Secondly we expect to see the exact number of hours that are contract wise in place per person per month. In order to get a clear overview, we also expect hours to be registered to the correct issues.
  As you all will have time which can not be related to a issue/project directly, e.g. a meeting, you can add these to running tickets (as long as they are booked in the correct month it is correct).
  During the hour logging you can indicate in the comment it concerned a meeting or so.
  Specifically for consultants it is important the total hours in Jira correspond to the hours declared, these will be compared to the sign off hour sheet.
  We do not consider time registration limited to consultants only. It is meant for the whole Business Applications train.
  
• Version manager Naming convention to create versions:  [System/Application].[Major version number].[Minor version number]
• Xray Test Management tool (app)

...

YPM Issue types

...

Image Removed A Project is a set of activities to deliver one or more outputs in accordance with a specific business case. A particular project may or may not be part of a program. 

Image RemovedEpics are large bodies of work that need to be completed over several sprints or over a longer period of time.

Image RemovedDeliverables are generic output that is similar and required for each project and epic (FD, TD, HLD)

Image RemovedTest  If needed, the deliverable for testing is moved to Issue type Test upon working on the issue.

Image RemovedEnhancement

...

Documentation for FD and TD is written in Confluence under  Project and Programme documentation and needs to be linked to the YPM project and respective EPIC.
A HLD should always be documented under the MAIN project Image Removed, so highest level. Depending on the complexity of a project (as soon as 2 or more applications are affected) EPICs will be the key to record TDs under.
Although recorded under the EPIC, all TDs should refer/link to the HLD or HFD.

It can be that a project belongs to a Programme (multiple projects delivering functionality of value, e.g. the e-bike programme). If that is the case (recognizable on project level by checking the TICKET GROUP),
documentation of the project should be under the Programmes section in the project documentation section under of the portfolioboard. All non-programme projects are documented under YME Portfolio Projects.

Software delivery projects

Yamaha IS Projects (YIS) 

Project YIS is set up as a single space to allow Information Systems to align on an Agile way of working, as part of the Agile Transformation.

Together we strive to arrive at a Jira configuration that is usable for all teams, supporting all YME Information Systems processes in a comprehensive, simplified manner.

Issuetypes

Image Removed

Issuetypes have a hierarchy to them:

Items in YIS project build on the Programmes or Projects created in YPM. An Epic should always be linked to one of these, so it is clear which strategic initiative it's part of.

An Epic is a large feature, that is broken down into its component Stories by a scrum team.

A Story is a feature that can be tested separately, and is part of an Epic.

A Sub-task is an activity that needs to be performed to complete a higher-level issuetype. It's always part of another issuetype.

Image Removed

At the same level as Story, other Product Backlog Items exist with slightly different meanings:

A Bug is a broken feature found outside of sprint;

A Change Request is a change to an existing feature, requested during UAT;

A Defect is a broken feature found during UAT;

A Spike is a Proof of Concept or other research required to prove the feasibility of a solution;

A Task is a Non-Functional Requirement, work in software development that brings no value to business yet is necessary (for example: code refactoring).

For testing using addon Xray, the following issuetypes exist. These are used solely by testers, to plan their work:

A Precondition describes the correct starting point of the test case. It can be a user's configuration; or a required object status, "with product _1" for example; or some permission that needs to be set before a test case is run.

A Test describes a single test scenario;

A Test Execution reports the execution of a Test;

A Test Plan is a container for test cases, usually related to a single sprint.

A Test Set collects Tests that logically belong together, so they can easily be resused, for example for planning of UAT.

Workflows

This project contains three workflows, with the distinction being made whether an item contains a software release (development workflow) or not (four step workflow).

Image Removed

Any work that can require a deployment uses the "Development" workflow:

Image Removed

These workflow steps are intended for:

• Backlog: work has not started;
• In progress: a developer builds & unit tests their own work to meet acceptance criteria;
• Review: a peer reviews any code & functionality;
• Ready for test: waiting for a QA officer;
• In test: QA officer is performing integration test & regression test;
• In UAT: PO/business validate that the functionality is as required, or provide feedback;
• Done: the work is completed without deployment needed; or
• Ready for deployment: the work is done & documented, but deployment to production is needed;
• Scheduled for deployment: deployment date is set;
• Done deployment: the solution is available and working on production.

Any issue-type that will not include a deployment uses the simplified "Four-step" workflow:

Image Removed

Epics have three additional statuses for Product Owners to prepare the work:

Image Removed

These workflow steps are intended for:

• Epic created: work has not yet started (this specific status allows easy searching for open Epics);
• Define business case: the goal of the epic needs to be made clear - what is the current situation, and why do we need to change this?
• Define acceptance criteria: we can only celebrate the success of an initiative, if we make clear how we will measure success - what is the acceptance criteria?
• Assign team: only after the business case and acceptance criteria are clear, does it make sense to involve a development team.

Field configuration

Yamaha Teams

This is a drop-down fields of all teams that exist within YME Information Services. When a new team is founded, an entry is added to this field.

For example, the entries on 16/11/2023:
Image Removed

Any team board uses this field to filter on, so it's mandary to fill in at ticket creation, so that the item will show up on the correct team board.

Image Removed

N.B.: In the past a free text field "Team Yamaha" was used, in which typing errors caused for tickets to get lost. This old field is in the process of being phased out, so you may still see it on certain screens.

Fix/version

When closing an item, it is mandatory to fill the field Fix/Version.

The fix/version is used to assign completed developments to a release scheduled to go to production.

Additionally, on Kanban boards, closed items will disappear from the board once a fix/version is closed, not earlier.

YIS: DoD projects

When closing an item, it is mandatory to full the field "DoD projects":

Image Removed

A Definition of Done (DoD) is a term from the scrum framework, which describes the agreement of what it means when an item is set to "Done" status. 

Within YME the intent it to validate these three organization-wide requirements for each ticket, because YME is being audited on these three points. For this reason, it is expected that this field will become mandatory across all YME projects in Jira.

N.B.: Jira COP wishes to limit the field to only being mandatory when a release is involved, this is a planned improvement.

Bonus features of YIS

DOR

Scrum teams generally use a Definition of Ready to clarify whether a Jira issue (Product Backlog Item, or PBI) can be taken into sprint. Within Jira, this process has been summarized in a field, "DoR", which allows tracking what an issue needs to become ready for development.

The generalized DoR steps are:

1. PBI created 
2. User story defined
3. Acceptance criteria defined
4. Refinement & estimation done
5. Ready for sprint

We find that most teams follow similar steps, so should be able to make use of this field.

Image Removed

N.B. This is an optional feature. Set the field manually in refinement sessions, in case that makes sense for your team.

Card colours

Based on the DoR field, PBI's receive a card colour on the standardised YIS scrum and kanban boards.

Image Removed

This way it's easy to see whether PBI's are ready for sprint:

Image Removed

YIS Product Owner boards

For Product Owners (PO's) who want to collaborate across teams, we can set up a Product Owner Board.

A PO board shows all Epics, Projects, and Programmes for teams who work on a single solution, enabling PO's to prioritise large initiatives together, and prepare new initiatives before these are assigned to development teams.

Here is an example for PO's Salesforce. Notice how certain epics are assigned to the group "PO Salesforce" to prepare further, instead of a development team:

Image Removed

Remember that a development team only sees Epics that are assigned to their Yamaha Team development team.

A PO board follows Epics across the board in a Kanban flow, using the YIS Epic statuses:

Image Removed

More complex Jira features

4.1 Jira SD-> B2C-Incident ticket creation

...

Image Removed

With this option many fields will be copied, like previously was done for CAB.
See below fields that will be copied/set:

Unfortunately it is not possible to copy all comments, but last comment and the comment entered in the comment screen that pops up if this transition is used will both be copied to the new B2C incident.

Add-ons used by Information Systems

...