Table of Contents
In this chapter below the Jira setup for Yamaha Motor Next Stage project (YNSEU) is explained. 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.
The Yamaha-motor Next Stage Jira Project Management Policy includes information like purpose of Jira implementation, progress management and rules.
Note: This presentation explains full setup done for YNS in PWC US. Jira YME is limited to EU Rollout Projects information only.
Loading of the presentation will take a while, please download the presentation to view the slides. We do advise you to check the Way of Working summary first, as this is the latest version and focused on team collaboration in a more concise manner.
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 |
---|---|
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! |
EPIC | Fourth level in YNSEU, but not residing as issue type there. EPICS reside under YIS and are meant for the power teams to do the work in. It is used to break up the features in to manageable iterations. EPICS are open for the maximum period of a quarter, and are used to plan QRP (quarterly release planning). EPICS only have 1 responsible team. Multiple teams working on a feature, means multiple EPICS. EPICS cannot be closed UNLESS the stories and tasks are completed. |
Task | Part of an EPIC, usually there to record non-development work. Can only be closed after completion of sub-tasks! |
Story | Part of an EPIC, usually there to record development work. Can only be closed after completion of sub-tasks! |
Sub-Task | Part of a story or task, usually there to break up work in smaller pieces. |
Decision | Stand alone issue type in YNSEU, used to record any decision we need to record and report upon. |
Defect | A non-production related bug, coming from a unit or user test that needs fixing. |
Bug | A production malfunction that requires fixing |
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 Advanced Roadmaps (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.
The YNSEU project also has some other issuetypes, like DECISION which are only used in the YNS project.
From EPIC level, the work is stored in the Jira PROJECT YIS (Yamaha Information Systems).
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.
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
Incoming dependency: blocks
Outgoing dependency: is blocked by
Defect
Incoming dependency: defect of
Outgoing dependency: has defects
Users (licensed user) 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.