Table of Contents

Introduction

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. 


YNS Jira Training


YNS project structure

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 .

Taxonomy YNS Issue Types 

ISSUE TYPEUSAGE

Capability

Highest level in YNSEU. Used to split the project in L1 processes. Capabilities can only be closed if underlying MILESTONES are closed!

Milestone

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!

Feature

Third level in YNSEU. Used to group bigger activities (mini projects) under a PDD. Features can only be closed if underlying EPICS are closed!

Decision

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!

Epic

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.

Only applicable for Agile teams: Epics are open for the maximum period of a quarter, and are used to plan QRP (quarterly release planning).

Story

Part of an EPIC, usually there to record development work. Can only be closed after completion of sub-tasks!

Task

Part of an EPIC, usually there to record non-development work. Can only be closed after completion of sub-tasks!

Defect

A non-production related bug, coming from a unit or user test that needs fixing.

Bug

A production malfunction that requires fixing.

Sub-Task

Part of a STORY or TASK, usually there to break up work in smaller pieces. 


YNSEU Project structure in Roadmaps/Plans

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).

Prerequisites for seeing / viewing FEATURES, EPICS, STORIES and TASKS in PLANS

PLANS are setup based upon filters. For the YNSEU project, we filter upon:

FieldValue
WorkstreamEU XXXXX
ComponentYNS
TeamDrop 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: 

  • All YNSEU Milestones and Features have a parent link to one of the above higher hierarchy levels. 
  • Where applicable field Workstream and Yamaha Team(s) will be filled in YNSEU.
  • All YIS activities on Issue type level Story (eg: Story, Task, Bug) need to be linked to a YIS Epic.
  • All YIS Epics related to YNS EU rollout have a parent link to a YNSEU Feature.
  • All YIS issues (eg: Story, Task, Bug) have a epic link to a YIS epic that is linked to a YNSEU Feature.
  • All YIS activities related to YNS EU rollout require to have field Workstream and Yamaha Team to be filled.
  • Fields Target Start and Target End date are required to be filled to make the planning visible Jira Roadmap plans for level 1 until 4 Epic.

Scrum teams can add Stories to their sprints will then also reflect on the plans.

Workstream

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:

  • EU Accounting
  • EU Master Data
  • EU Project Management
  • EU Rollout (Gr1_Ph1)
  • EU S&L
  • EU S&L (P&A)
  • EU S&L (Units)
  • EU S&L (WTY)
  • EU Technical Support

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.

Component

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

Teams can be selected in YNSEU Jira Project via Yamaha Team(s) (multi select)  and in YIS via Yamaha Team (single select) field.

  • AVENGERS
  • B2C-CDP
  • B2C-DIGITALUM
  • B2C-EPAM-DEVOPS
  • B2C-EPAM-MOTORS
  • B2C-EPAM-WAVERUNNERS
  • CLOUD-RANGERS
  • CRM-KANDO
  • DRAGONBALL
  • EU Accounting
  • EU S&L (P&A)
  • EU S&L (Units)
  • EU S&L (WTY)
  • LIGHTBEAM
  • MARVELS
  • QUICKSHIFTER
  • TRANSFORMERS
  • TRICITY
  • WOLVERINE
  • YAMALUBE



Yamaha Motor Next Stage (YNSEU)

YNSEU Issue Types

YNSEU: Issue Type Scheme contains the following Issue types:

YNSEU issues overview

YNSEU Specific Fields


  • Component's:  Predefined set of labels, Component YNS  is automatically added upon creation of an YNSEU Issue.
  • Decision Type:  Single select list, to indicate the Decision type, is only applicable for issue type Decision
  • Application(s):  Multi select field to indicate affected application(s), is only applicable and mandatory for issue type Decision
  • Workstream:  Used to distinguish which project  items are linked to and is mandatory to be filled in ANY issue type
  • Dependent Workstream: Used to distinguish which project items are linked as 'secondary workstream' and to specify dependencies
  • Phase: Used to indicate to which Project Phase this issue belongs to
  • Yamaha Team(s):  Yamaha Team is a multi select drop down field which is used to indicate which team is involved for this issue and to have the issue reflected on the teams Dashboard or Board.
  • YNS Deliverables: Used to indicate to which stage of Deliverable this issue is part of
  • %Completion: Completion percentage for YNS work.
  • Final Decision: Multi line Text field to capture the final decision for issue type Decision. This is mandatory to be filled when closing a Decision.
  • Target start: Planned start date when a team will start working on the issue. Used in Advanced Roadmap Plans. To be filled by YNS Workstream lead, YNS PMO or PO.
  • Target end: Planned end date when a team will complete the work on the issue. Used in Advanced Roadmap Plans. To be filled by YNS Workstream lead, YNS PMO or PO.
  • 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. Not applicable for issue type Decision
  • 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. Not applicable for issue type Decision



YNSEU Workflows


The YNSEU project contains 2 workflows.

  • YNSEU Four Step (To Do, In Prog, In Rev, Done) Workflow
  • YNSEU Decision Workflow

YNSEU Four Step (To Do, In Prog, In Rev, Done) Workflow

 This workflow is used for issue type Capability, Milestone and Feature.

  • To Do: work has not yet started;
  • In Progress: The work on the high level structure issue has been started, Target end and Target start date must be filled. 
  • On Hold: High level structure item is put on hold when it is not possible to proceed 
  • Done: This high level structure item has been completed, including all underlying issues.
  • Canceled: No further work will be done on this high level structure issue, it is not required anymore or has become obsolete.


YNSEU Decision Workflow 



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

  • To Do: work has not yet started;
  • In progress: the Decision subject is being discussed with stakeholders;
  • On Hold: Status used if a Decision is set on hold;
  • Done: The Decision has been made. Fields Decision Type, Application(s), Workstream and Final Decision are mandatory to be filled before closing a Decision.  Final decision should only be updated when all parties agree on the decision.
                Once the decision is final and issue is marked as “Done”, the decision made will be shared via e-mail with the YNS project team members through an automated function.
  • Canceled:  The situation about which a decision had to be made no longer occurs and has become redundant.  Fields Workstream and Final Decision are mandatory to be filled before canceling a Decision.

YNS Decisions can be found on the following dashboard: YNS-YME Decisions Dashboard


YNS Issue creation

YNSEU Issue creation

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.


YNSEU Decision 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.

YIS Epic creation 

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.


CREATE an EPIC parent link to a FEATURE 

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.

  • EDIT  the EPIC
  • Go to PARENT LINK
  • Type the name of the feature and save the change.

Result should be something like this: 

CREATING a STORY or TASK and LINK it to the correct EPIC

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. 

CREATE a FEATURE parent link to a MILESTONE

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. 

DEPENDENCY on EPIC, STORY, TASK or any other issue type

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

Confluence page link to a Jira Issue

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. 

Communication

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. 

Managing your work

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:

YNS DASHBOARDS

  • Default Dashboard: Personal Issue tracking dashboard 
    • System Dashboard
      Includes the following filters:
      • Introduction with link to Customer portal and Portal user guide
      • All my open assigned issues
      • All my request participant
      • Issues I'm mentioned in
      • All my open watched Issues
      • Open project tickets

  • Dashboards for YNS Project management





TEAM BOARDS

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.

ROADMAP AND PLANS








  • No labels