Table of Contents
In this chapter below the Jira setup for Yamaha Motor Next Stage Project structure in Jira is explained. It includes an explanation of YNS Project Structure of working in Jira for project Yamaha Next Stage (YNSEU) and Yamaha IS Projects (YIS).
Never worked with Jira before? No problem. Please first read the Jira training Basics page.
By managing the 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.
YME will maintain all work done for all EU rollout Project in YME Jira, project YNSEU. YME documentation related to YNS is stored under Confluence Space IF where the integration teams collectively work in.
In principle all work relates to specific PDD MILESTONES. Under a MILESTONE, the Project team will specify FEATURES of a PDD where the teams can connect their EPICS to. See the project org structure in Jira below.
Collaboration with YNS teams is done in Jira via the YME YIS project. Teams information can be found here.
The YNS teams procedures, way of working agreements etc. can be found here: YNS Teams - Procedures Guidelines Onboarding WoW .
| ISSUE TYPE | USAGE |
|---|---|
| Highest level in YNSEU. Used to split the project in L1 processes. Capabilities can only be closed if underlying MILESTONES are closed! |
| Second level in YNSEU. Used to divide the project to the level of Process delivery document (PDD) (L2,3,4). Milestones can only be closed if underlying FEATURES are closed! |
| Third level in YNSEU. Used to group bigger activities (mini projects) under a PDD. Features can only be closed if underlying EPICS are closed! |
| Stand alone issue type in YNSEU, used to record any decision we need to report upon. Decision can only be closed when fields Workstream and Final Decision are filled! |
| Fourth Level for YNS, Highest level in YIS. Epics are meant for the teams to do the work in. It is used to break up the Features into manageable iterations. Epics only have 1 responsible team. Multiple teams working on a feature, means multiple Epics. Epics can only be closed if underlying STORIES and TASKS are completed. |
| Part of an EPIC, usually there to record development work. Can only be closed after completion of sub-tasks! |
| Part of an EPIC, usually there to record non-development work. Can only be closed after completion of sub-tasks! |
| A non-production related bug, coming from a unit or user test that needs fixing. |
| A production malfunction that requires fixing. |
| Part of a STORY or TASK, usually there to break up work in smaller pieces. |
ADVANCED ROADMAPS, an integrated feature of Jira, can be used to visualize the project structure and progress. It can also be leveraged to report on dependencies.
The hierarchy and full progress of YNSEU can be tracked in Jira training Plans (plans) under YNS Program Roadmap.
Team progress can be tracked under the team plans.
It can be found under PLANS and then YNS ROADMPAP.
Opening PLANS and then particularly the YNS Program Roadmap will give you a similar look as the screenshots below. Explanation on how to read the project structure is provided there.
The YNS project is structured according level 1 processes:
Highest level, it the L1, which can be Quote to Cash (QtC) or e.g. Deliver to Replace. L1 processes can be found here.
The project structure is stored in Jira PROJECT YNSEU. It ends at the level of FEATURE.
From EPIC level, the work is stored in the Jira PROJECT YIS (Yamaha IS Projects).
Also other Issue types on Issue level (Story, Task, Bug, Defect) are used in YIS.
Sub-Tasks is the underlying level which can also be used for Story, Task, Bug, Defect to break down the work.
DECISION Issue type is stored in YIS, but only used for YNS Project planning.
In there we have the following structure:
Software Development and task execution within YME is done in project Yamaha IS Projects (YIS). YIS Documentation can be found on the following page: Jira training for Yamaha IS Projects (YIS).
PLANS are setup based upon filters. For the YNSEU project, we filter upon:
| Field | Value |
|---|---|
| Workstream | EU XXXXX |
| Component | YNS |
| Team | Drop down list |
| Ticketgroup(s) | Optional, advised to use for QRP planning, managed by PO's. The options to use: QRP-Year-Q(uarter) |
These fields are expected to be filled out. If you forget either of them, you will not be seeing your issue in the roadmap overview.
Next:
Scrum teams can add Stories to their sprints will then also reflect on the plans.
The “Workstream” field in YNS Jira is used to distinguish which project the items are linked to and is mandatory to be filled in ANY issue type for proper project structure in Advance Roadmaps or any other dashboard PMO is using.
All related EU Rollout Projects in YNS Jira can be found under the following workstreams:
Field "Dependent Workstream" is also available but is not mandatory. This is more to specify dependencies. Dependencies on tasks, stories or epics MUST be indicated/visualized via a BLOCKED BY link in the respective issue type.
The component field is having a predefined set of labels one can select from. For the YNS project, it is required to use YNS for each story, tasks or epic, feature, milestone or capability.
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: 
Teams can be selected in YNSEU Jira Project via Yamaha Team(s) (multi select) and in YIS via Yamaha Team (single select) field.
YNSEU: Issue Type Scheme contains the following Issue types:
YNSEU Specific Fields
The YNSEU project contains 2 workflows.
This workflow is used for issue type Capability, Milestone and Feature.
For creation of a Decision the following fields are set as mandatory to be filled: Workstream, Decision Type, Application(s), Workstream
Please read also the YNSEU Decision Issue Creation instructions
YNS Decisions can be found on the following dashboard: YNS-YME Decisions Dashboard
Users (licensed and authorized users) can use the 
button anywhere in Jira from the top bar.
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: 
Issues can also being created via the Board or backlog. Detailed instructions can be found in Jira training Basics - Issue Creation.
An YNS DECISION is ALWAYS created in the YNSEU project. YNS DECISIONS are the responsibility of the PO's and WS leads and PMO team to maintain. They are the owners.
Creating an Decision is considered to be a basic skill for members (via CREATE). See also the Jira Basics Training. You need to follow that training first, before you continue this manual.
For YNS there are some specifics one must be aware off.
Phase: Select the relevant Phase when necessary
Workstream: Select the workstream that has started the Decision
Dependent Workstream: Select the those other workstreams that are relevant.
Decision Type: Always select “YME Internal”. “YME-YMC Liaison” is only for PMO.
Applications: Select all relevant applications that are affected by this decision
Yamaha Teams: Select the relevant Yamaha Team(s) involved in the decision making
Target start date: Select the start date of the decision making
Target end date: Select the end date when the decision has to be made.
If further explanation of the decision is required you can link it to the Parent or Epic or any other concerned issue(s). For example, if there is a decision linked to PDDs, you can add the Parent/Epic link to the respective PDD topic
Before closing a Decision field Final Decision is required to be filled. Please read instructions under: YNSEU Decision Worklfow.
An EPIC is ALWAYS created in the YIS project. YNS EPICS are the responsibility of the PO's and WS leads to maintain. They are the owners.
Creating an EPIC is considered to be a basic skill for members (via CREATE). See also the Jira Basics Training. You need to follow that training first, before you continue this manual.
For YNS there are some specifics one must be aware off.
Here you see the component being filled with YNS, you see a correct parent link to the feature and the workstream is correctly filled out (EU S&L (UNITS)).
To plan for a QRP, PO's will also set the TICKETGROUP(s) to the quarter of delivery (e.g. QRP-2024-Q1). This helps to create a special advanced roadmaps filter solely focusing on what teams have committed to for a quarter.
One important thing to understand is the place in the project structure before you make a link towards a FEATURE. Check the YNS roadmap, find your PDD and milestone under it and not the feature YNEU number you want your EPIC to be linked to.
Result should be something like this:
A story or task should always be tied to an EPIC. You will not see them in the project org structure if you forget to do that.
Connecting may only be done by creating an EPIC LINK. That is a particular link field that you can see when you edit a story or task. Type the name of the epic in the epic link field, select it and a story is connected.
When you create a story directly out of an EPIC, you do not need to do this, then the link is instated automatically.
Usually this is only done by PMO or WS leads, and means we are specifying the project better. The action is similar to making a parent link within an EPIC.
The difference is you need to first create a FEATURE or find an existing FEATURE and know to which MILESTONE it needs to be connected.
Dependencies show the relationship between issues for blockers or contingencies, the following link type will be treated as a dependency and is visible in PLANS.
Creating a link is done out of any issue type via MORE, LINK. Depending on the direction of the dependency you can select one of under mentioned link types.
Blocks (can be used for any issue type)
Incoming dependency: blocks
Outgoing dependency: is blocked by
Defect
Incoming dependency: defect of
Outgoing dependency: has defects
It is very helpful to have documentation links out of issues to have quick material reference available. Eg. a functional spec should be tied to the story recording the activity.
You can make that link best out of the confluence page, in which you have to include a Jira ISSUE Link. Within Confluence, in the EDIT mode of a page, you can go to the + plus pictogram and use insert Jira Issue.
Type the YIS or YNSEU issue and confirm. After saving, it will collect the status of the referenced Jira issue and reflects that in a nice manner.
In the YIS or YNSEU issue, you will see a wiki link, which is a hyperlink to the confluence page.
It is key that communication on topics is consolidated to the issues covering them. This is to secure no information is lost, and we have a complete history in one place.
Within the issue types we use within the YNSEU and YIS project, we use the COMMENT functionality for communicating to the stakeholders (watchers, reporter, assignee) or even a particular person, not being in the stakeholder list (condition: that user must have Jira licenses)
You can pin-point communication to a particular recipient by using the "@" sign.
There are a couple of ways to get track of your work (or the work a team does). Underneath some options you can leverage from:
All YME agile teams work with a YIS Board This can be a Scrum or Kanban Board.
Via Boards>View all Boards and search on YIS or Team name the results will be visible to access the Team board.
Capability
Milestone
Feature
Decision
Epic
Story
Task
Defect
Sub-Task