Never worked with Jira before? No problem. Please first read the Jira training Basics page page.
In this chapter This chapter is part of is part Jira training for Information Systems, below the Jira setup for Information Systems - Yamaha IS Projects (YIS) is explained.

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.

Yamaha

...

Project YIS is a Software delivery Project.

YIS Issuetypes

...

Next Stage Project (YNS) Backbone Sync

To support the Yamaha Next Stage (YNS) Project a Backbone Sync has been setup. More details information can be found on Space: Jira training for Yamaha Motor Next Stage Project (EUYNS)

Below two sections are most relevant for YIS:

Note
Per 01 Jan 2024 The Backbone Sync has been stopped between YIS and YNSEU. A new project structure and way of working has been setup in YNSEU. Eventually Yamaha Next Stage Project (EUYNS) will be phased out.

Yamaha Next Stage Project (YNS)

Yamaha next Stage project within YME Jira is managed within two Jira Projects, YNSEU and YIS.
High Level planning for the YNS project and Decisions are logged under project YNSEU.
Team work is all done within project YIS and the following issue types are supported for YNS Project planning: Epic, Story, Bug, Defect, Task and Sub-Task.

For the project tracking of YNS specified fields have been introduced to YIS. Examples are fields Workstream and Dependent workstream. See the full list under chapter YNS Specific fields
Also Workflow for Story, Bug, Defect includes an additional status like 'On Hold' that can only be used specifically for YNS related issues.
Validation to use this status is that the Workstream field cannot be empty.

Epics related to the YNS project are linked to a Feature in the YNSEU Project.
More information about the YNS Project Project structure and YNSEU Project can be found here: Jira training for Yamaha Motor Next Stage (YNSEU)

Yamaha IS Projects (YIS)

Project YIS is a Software delivery Project used by agile teams working Scrum or Kanban.

YIS Issue types
Anchor
YIS_Issue_Types
YIS_Issue_Types

YIS: Issue Type Scheme contains the following Issue types:
Image Added

Issue types have a hierarchy to them:

Items in YIS Jira-project are build on a Image AddedStragetic Theme or Image AddedIniative in YPB (Yamaha Portfolio Board) . More detailed information about YPB setup can be found here: Jira training for Yamaha Portfolio Planning (YPM).
AnImage Added Epic should always be linked to one of these, so it is clear which strategic initiative it's part of.

Explanation per issue type used in YIS:

AnImage AddedEpic is a large feature, that is broken down into its component Stories/Tasks etc. by a scrum team.

AImage AddedStory is a feature that can be tested separately, and is part of an Epic.

AnImage AddedEnable Story is a change to a production system, solely used by Enable Train with expert and manager approval beforehand. (It replaces the outdated J-SOX CHANGE process).

Image Added

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

AImage AddedBug is a problem which impairs or prevents the functions of a feature.

AImage AddedDefect is a problem which impairs or prevents the functions of a feature during UAT.

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

AImage AddedSpike is a Proof of Concept or other research required to prove the feasibility of a solution;

AImage AddedTask is a quick activity that contains no deployment or business value.

AImage AddedSub-task is an activity that needs to be performed to complete a higher-level issue type. It's always part of another issue type.

For testing addon Xray is used, the following issue types exist. These are used solely by testers, to plan their work;

AImage AddedPrecondition 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;

AImage AddedTest describes a single test scenario;

AImage AddedTest Execution reports the execution of a Test;

AImage AddedSub Test Execution represents sub-task tests executions;

AImage AddedTest Plan is a container for test cases, usually related to a single sprint;

AImage AddedTest Set collects Tests that logically belong together, so they can easily be reused, for example for planning of UAT.

YIS Issues overview

YIS has two field configurations:

YIS Field Configuration, this is used by default
YIS sub-task Field Configuration, used by Issue type Subtask.

YIS Mandatory Fields

Image Added

Type: Automatically filled

Priority: By default issues are set to Low

Yamaha Team: Determine responsible team who will be working on this issue and is required to make it visible on a Board/ Dashboard/ Plan

Resolution: Required when issue is closed

Fix Version/s: required for Story or Enable Story when status is set to Done Deployment

YIS Specific Fields

Example Fields overview for Issue type Story, Sub-task:

Image Added Image Added

All used issue fields in YIS are explained below:

Type: Issue type used, see list under YIS Issue types
Priority: By default issues in YIS are set to priority Medium
Image Added
Affected Version/s: field is by default empty, can be filled with affected version/s used for releases.
Business value: used to estimate (in a Fibonacci range) the value of that piece of development to the YME business.
Labels: tags or keywords that can be added to issues to show whether they possess certain characteristics. If a issue is related to BAU (Business As Usual) activities label BAU is added.
Epic Link: link to epic issue(s) (large feature).
Sprint: Multi select field to link the issue to a sprint.
Image Added
Requirement status: The requirement test status by version or test plan, is used by XRAY and applicable for issue type Story and Change request.
Image Added Image Added
Application-Module: Single select list of applications (products) and modules (programs).
Solution Group : This field is used to select a single department that the Yamaha Team falls under. Based upon this field the ticket will appear in the Dashboard queue/filter of a department (manager).
When all agile teams are formed this field will be phased out for YIS Jira -project.
Image Added
Yamaha Team: Yamaha Team is a single select drop down field which is required for all issue types used in YIS.
Image Added
This field includes all teams that exist within YME Information Division. When a new team is founded, an entry is added to this field.
For example, the entries on 18/07/2023:
Image Added

Any team board uses this field to filter on, so it's mandatory to fill in at ticket creation, so that the item will show up on the correct team board.
Image Added
N.B.: In the past a free text field "Team Yamaha" was used (team#******), 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.
Target release date: used to track the intended release date aligned with stakeholders.
Ticket group(s) Multi select field used to group stories and bugs under a YPM Programme/Project or QRP
Image Added
Image Added
Story Points: used to estimate (in a Fibonacci range) the complexity, effort, and risk inherent to the story. Story Points field available for issue type Change request, Task, Story, Bug, Defect, Spike.
DOR: DOR is the abbreviation forDefinition of Ready. 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.
Image Added
The generalized DoR steps are:
1. Issue created
2. Requirements defined - the use case & acceptance criteria are clear, why we want to do this and how we will test;
3. Prioritized against other work - the product owner has ranked the items in priority;
4. Refinement & estimation done - developers understand the item and have added estiamation;
5. Ready for work - any dependencies are managed and the team can start the development.

N.B. This is an optional feature. Set the field manually in refinement sessions, in case that makes sense for your team.
DoD projects: 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.
When closing a Story, Bug or Defect, it is recommended to fill the field "DoD projects".
Image Added
Image Added
Design Review: Optional field activated on Epic, Story, Bug, Defect and Spike, Task . Field is set to track Design Review for solution design, technical design, tech review.
Default is set to 'To be determined'. If value is set to “Yes” or “Completed” it will show up on the Design Review board. Architects can then deliver input on the design and mark as completed when review is finished.
Image Added
Installation instructions: Optional field used by some teams to store details for deployment, for example if configuration is required or run a SQL on production system.
Type of work: Field to track type of work activated for Issue type Story, Spike, Bug, Task
Image Added
Technical debt: Efforts spent on improving the codebase, enhancing its structure, refactoring, and optimizing it without adding new functionality.
New Development: Efforts dedicated to developing new features, functionalities, or significant enhancements.
Maintenance: Efforts involved in maintaining the system, which includes activities like routine updates, performance tuning, etcetera.
Bug Fixing: Efforts expended to identify and resolve defects or issues reported in the system.
Status: Workflow status summary.
Resolution: Resolution is set automatically when an issue is closed.
Status Resolution Description
Done Done The task/configuration has been completed.
Done Deployment Done - Deployment Deployment has been completed.

For Status Canceled a resolution can be selected when the issue is going to be closed

Status	Resolution	Description
Canceled	Cannot Reproduce	The problem cannot be replicated or is not clear.
Canceled	Duplicate	The issue is a duplicate of another issue.
Canceled	Won't Do	The issue will not be addressed, often used for non-issues or low-priority items, or the business has decided not to implement the requested feature.

Fix/version: Mandatory field 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.
Note: Single text field used for reporting for POs, Trainleads and teams to see at a detailed level in one view what exactly needs to be discussed or informed about a story, task or epic.

Target start: Planned start date when a team will start working on the issue. Used for Advanced Roadmaps plans.
Target end: Planned end date when a team will complete the work on the issue. Used for Advanced Roadmaps plans.
Baseline start date: Read only field. Used to indicate original planned start date, will be set automatically when for first time target start is set. Applicable for issue type Epic, Story, Enable Story, Task, Bug, Defect, Spike, Change request.
Baseline end date: Read only field. Used to indicate original planned end date, will be set automatically when for first time target end is set. Applicable for issue type Epic, Story, Enable Story, Task, Bug, Defect, Spike, Change request.

YNS Specific fields
Anchor
YNS_Specific_fields
YNS_Specific_fields

Applies to YIS Issue types: Epic, Story, Bug, Defect, Task, Subtask

Component/s: Component YNS is mandatory to indicate that an issue is part of the YNS project.
Component YNS is automatically added for all YNSEU issues and for YIS where Workstream field is filled
For Initiative Ympulse 1.5 component Y1.5 is automatically added for all child issues in YNSEU and YIS linked to Milestone YNSEU-1243
For Initiative Ympulse 2.0 component Y2.0 is automatically added for all child issues in YNSEU and YIS linked to Milestone YNSEU-1745

Example: Image Added
Phase: Indication in which phase the YNS project item is.
Workstream: EU workstream for YNS (Yamaha Next Stage) Project
Dependent Workstream: EU dependent workstream for YNS (Yamaha Next Stage) Project
% Completion: Completion percentage for YNS work.
Partner Issue Key YME: Single text view only field, automatically filled for issues synced between EUYNS ↔ YIS. Used for YNS project reporting.
Test Phase: Single select drop down field to indicate test phase of a defect. Only applicable to issue type Defect.
Defect CategorySingle select drop down field to indicate the category. Only applicable to issue type Defect.

YIS Workflows

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

Image Added

Generic Epic Workflow

An Epic is a large feature, that is broken down into its component Stories by a scrum team. Epics is mainly used by Product Owners and (Service) Delivery Managers forforpreparing the (Project) requirements :

Image Added

These workflow steps are intended for:

To Do: 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?
Secondly, we can only celebrate the success of an initiative, if we make clear how we will measure success - what is the acceptance criteria?
Refinement: only after the business case and acceptance criteria are clear, it make sense to involve a development team and to refine the Epic.
In progress: the development team is working to meet acceptance criteria;
On Hold: Status only used for issues related to YNS, Workstream field is mandatory to be filled;
Done: the work is completed with deployments done on underlying items;
Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete.

Generic Development Workflow

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

Please note that on 27 Feb 2024 17:00 CET the new workflow for B2C/YIS has gone live (update image after go-live):
Image Added

These workflow steps are intended for:

To do: work has not started (work can always move back to this status);
In progress: a developer builds & unit tests their own work to meet acceptance criteria (work can always move back to this status);
Review: a peer reviews any code & functionality;
Ready for test: waiting for a QA officer (this step can be skipped);
In test: QA officer is performing integration test & regression test (this step can be skipped);
Validation: PO/business validates that the functionality is as required, or provides feedback;
Done: the work is completed without deployment needed (Resolution "Done" is set automatically); or
Ready for deployment: the work is done & documented, but deployment to production is still needed;

On Hold: Status only used for issues related to YNS, Workstream field is mandatory to be filled;
Blocked: Status only used for Consumer Train reporting;
Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete (a pop-up will allow filling the mandatory field Resolution); or

Acceptance: the work going through extensive UAT outside of the sprint (this step can be skipped);
Scheduled for deployment: deployment date is set (this step can be skipped);
Done deployment: the solution is available and working on production (fix/version is a mandatory field before moving to this status; Resolution "Done Deployment" is set automatically).

For some (B2B) Business Train teams a specific transition has been added to move an Issue from Ready for Deployment to Done Deployment, these options are only visible for users who can approve deployments as we need to adhere to J-sox regulations.
Image Added
BA Deployment : Used for deployments by Lightbeam team for Cognos, TM1, DWH. This options triggers an automation rule to inform stakeholders of the deployment.

Image Added
OMS Normal Deployment: used for Application-Module Ympact only and is available for B2B deployment approvers, this option triggers creation of a SD Deployment Request for OMS. This needs to be approved a IT manager/team lead and will after approval be set to Yamaha Team iSPARKLE-iSERIES for move to Production. Via a B2B deployment Distribution list and B2C deployment Distribution list stakeholders are informed of the deployment.

Image Added
OMS Interactive Deployment used for Application-Module Ympact only and is available for B2B deployment approvers , this option triggers creation of a SD Deployment Request for OMS. This needs to be approved a IT manager/team lead and will after approval be set to Yamaha Team iSPARKLE-iSERIES for move to Production. Via a B2B deployment Distribution list and B2C deployment Distribution list stakeholders are informed of the deployment.

Image AddedLogistics Deployment used for Application-Module SYS2000 and YLS and is only available for B2B logistics deployment approvers , this option triggers creation of a SD Deployment Request. This needs to be approved a IT manager/team lead and will after approval be set to same team as original YIS deployment ticket for move to Production. Via a B2B deployment Distribution list/ B2C deployment Distribution list stakeholders are informed of the deployment.

The steps in italics are shown on the deployment board, while "Ready for Deployment" or Done or Canceled is the final state on development boards.

The following statuses allow sprint closure: Done, Canceled, Ready for Deployment (and Acceptance, Scheduled for Deployment, Done Deployment).

YIS Enable Story Workflow
Anchor
ENABLE_STORY_WORKFLOW
ENABLE_STORY_WORKFLOW

Enable Story Is used solely by Enable Train and includes Expert and Manager approvals of the design before any development can be done:
Image Added

To do is the initial state the ticket is created in. It's not possible to move back to it.
Design is the planning of what to change and how to change it carefully, including which people to involve in communication about the change. This needs to be approved before implementation. Moving back to this state removes any Resolution set and means that approvals need to be redone.
Expert approval means that the solution direction is reviewed by an expert. Only those in the "expert" group can set the next status. A comment will be added to the ticket tracking who approved.
Management approval means that the communication plan is reviewed by a manager. Only those in the "manager" group can set the next status. comment will be added to the ticket tracking who approved.
Awaiting development means that the plan is ready, but the implementation is not yet started.
In process means that the implementation is underway. It's possible to move back to "in process" in case testing or validation finds faults. It's possible to skip testing in case there is no testing environment.
In test means that the solution is being verified in a test environment.
Validation means that the solution is being verified in the production environment.
Done deployment means that the solution is a success and the work is fully completed.

Please note that the Designer, Expert approver and Manager approver should be three different people.

Generic five-step Workflow

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

Image Added

To Do: work has not started;
In Progress: a developer builds & unit tests their own work to meet acceptance criteria;
In Test: means that the solution is being verified in a test environment.
Review: a peer reviews any code & functionality;
Done: the work is completed without deployment needed;
Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete.

Generic Sub-Task Workflow

The sub-task workflow is exactly the same as Generic Five-step Workflow, except that it pre-fills the Yamaha Team entry from its parent.

Image Added

YIS Issue creation

Users (licensed user) can use the Image Added button anywhere in Jira from the top bar.

Image Added

When using the create button the correct project and issue-type needs to be chosen and some other (required) fields as well. Required fields are marked with a red * .

Example: Image Added

Issues can also being created via the Board or backlog. Subtasks can being created via the original issue. Detailed instructions can be found in Jira training Basics - Issue Creation.

For a Story automatically a description is pre-filled.
Image Added

YIS BUG creation

Bugs can directly created via the Image Added button, see more detailed explanation above.
When a Bug has been registered via a Servicedesk ticket (SD) then automatically a YIS Bug issue can be triggered via SD workflow transition Bugfix-YIS.
Automatically the SD-issue will be linked to the YIS-issue and changes to status Awaiting development. Once the Bug has been resolved the reporter and requested participants can be informed via the SD-issue.
Only users with Bugfix creation permission are able to use this option.
For SD workflow see documentation under: Jira training for Yamaha Applications Support Desk (SD) - Software Delivery BUG/Incident issue creation via SD

Image Added

YIS Enable Story creation

A YIS Enable Story can directly created via the Image Added button. The create screen will be opened.
Fill in the required fields: Project, Issue Type, Summary, Reporter, Yamaha Team
Also fill the Epic Link if there is one.
Description can be left empty, a template will be automatically added after creation.

Then click on the Image Added button.

Image Added
Image Added
Open the newly created ticket (via (backlog) of your board)
Image Added
After creation a template is automatically added to the Description.
Change the Status to Design via the workflow button, assign the ticket to your name and enter the Change details in the Description field.
Then follow the workflow to request for approval before execution of the change.
Workflow explanation can be found under: YIS Enable Story Workflow

Image Added

YIS Boards

YIS works with 3 template boards.
These template boards have the same configurations across teams.

YIS Product Owner board

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 prioritize 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 Added

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 Added

YIS Scrum template

Within YIS all scrum boards use the same template, with the following configuration features:

Custom field "Business value" is used to estimate (in a Fibonacci range) the value of that piece of development to the YME business.
Something that cannot be used yet (partial development or a spike) has BV 0, while a development that benefits entire Europe might count as much as BV 13.
Custom field "DoR" is used to track the Definition of Ready, or PBI readiness for development.
Card colors show the stages:

Image AddedImage Added

The board contains quick filters to easily select only PBI's relevant for the specific person or meeting:

Image Added

Board Columns are named for the story status, though as long as multiple projects exists other statusses are also shows in these columns:

Image Added

"Days in column" is activated. Hovering over the dots shows the amount of days in column in text.

Image Added

Custom field "Target release date" is available to track the intended release date aligned with stakeholders.
When closing an item, the "Resolution" is set. This field is cleared when an item is reopened.

YIS Kanban template

Within YIS all Kanban boards use the same template, with the same configuration features as the scrum template, and in addition:

WIP limit set to team size: distribute the amount of developers over In Progress / Review columns, and the amount of testers over Ready for Test / In Test columns. The BA or PO validates items with status UAT.

Image Added

YIS Deployment Board

The work done in sprints ends when a PBI is either "Done" or "Ready for Release" in the item workflow. All items that require a deployment are next shows on the Deployment Board.

Since at the moment YME works with bi-weekly releases (and sometimes in-between hotfixes), this board collects all work across teams that still needs to be released.
For B2B Application teams documentation how deployment is done can be found on the following page: Deployment Procedures.

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

Issue types have a hierarchy to them:

Items in YIS project build on the Image RemovedProgrammes or Image RemovedProjects created in YPM. More detailed information about YPM setup can be found here: Jira training for Portfolio Planning.
An Image RemovedEpic should always be linked to one of these, so it is clear which strategic initiative it's part of.

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

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

A Image RemovedSub-task is an activity that needs to be performed to complete a higher-level issue type. It's always part of another issue type.

Image Removed

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

A Image RemovedBug is a broken feature found outside of sprint;

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

A Defect is a broken feature found during UAT;

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

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

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

A Image RemovedPrecondition 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 Image RemovedTest describes a single test scenario.

A Image RemovedTest Execution reports the execution of a Test.

A Image Removed Sub Test Execution represents sub-task tests executions.

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

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