Page History
...
The Change Advisory Board will be phased out completely as it will be covered by the Yamaha Portfolio Board and Software project(s).
J-sox compliance
YIS: DoD projects
When closing an item, it is mandatory to full the field "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. 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.
Yamaha Applications Support Desk (SD)
In Yamaha Applications Support Desk all operational support (BAU- Business As Usual) requests are registered that related 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
Issuetypes
Audit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.
Authorization 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.
Incident: Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal will have Issue type Incident.
RobotJob Change: Robot Job Change request used for Ympact Job scheduling
Deployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.
J-SOX requires companies to enhance internal control reporting and demonstrate the effectiveness of their internal controls.
To be SOX compliant, your organization will need to demonstrate 4 primary security controls:
- Secure Access Control Management. ...
- Demonstrate a Resilient Cybersecurity Framework. ...
- Demonstrate Data Backup Protocols. ...
- Change Management.
For Information Systems Division this means that the requested users manager need to be informed and the IT manager need to approve database changes or program changes that are required to solve an issue.
Beforehand it is not known if a database correction or program change is required, to prevent delay in resolving reported issues the users manager is automatically added to a ticket.
YIS: DoD projects
When closing an item, it is mandatory to full the field "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. 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.
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 
button should NOT be used for creation of a SD issue.
SD Issuetypes
Incident: Reporting a incident or outage. Currently all incoming issues submitted via the Jira Customer portal will have Issue type Incident.
Service Request: Request Service Request: Request for information, this issue type is currently not used anymore.
Workflow
If a (bug) fix for a appliction is required the Bugfix transistion can be used to trigger a issue being created in a Development project.
Change Advisory Board (CAB)
...
Audit: Used for J-sox change requests and IRY issues registered to deliver evidence for auditors.
Authorization 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.
RobotJob Change: Robot Job Change request used for Ympact Job scheduling
Deployment request: Triggered by Development software projects used by B2B teams for Ympact,Ympulse, Yamcom deployments.
SD Workflow(s)
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
...
One of the two following conditions must be met to create a CAB issue.
- Bugfix to deliver a functional/technical solution for the original SD issue. SD issue remains open until the fix has been applied.
- 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.
...
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).
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
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.
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).
Any work that can require a deployment uses the "Development" workflow:
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:
Epics have three additional statuses for Product Owners to prepare the work:
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:
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.
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.
J-sox compliance
YIS: DoD projects
When closing an item, it is mandatory to full the field "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. 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:
- PBI created
- User story defined
- Acceptance criteria defined
- Refinement & estimation done
- Ready for sprint
We find that most teams follow similar steps, so should be able to make use of this field.
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.
This way it's easy to see whether PBI's are ready for sprint:
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:
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:
Yamaha Portfolio Board (YPM) (project)
Enhancements, improvements and new functionality requests are raised via the Yamaha Portfolio Board (YPM) and can only be raised by Portfolio managers.
Functional Design (FD) and Technical Design (TD) activities and approvals are done in the Yamaha Portfolioboard (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.
...
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.
Epics are large bodies of work that need to be completed over several sprints or over a longer period of time.
...
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 , 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.
...
.
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.
Bug: Bugfix to deliver a functional/technical solution for the original SD issue. SD issue remains open until the fix has been applied.
Story: 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.
Under the SD issue the reporter and requested participants can be informed about the change applied/ to be applied but is also used to collect information from the requester.
CAB Workflow
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).
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.
Explanation off used issue types and YPM procedure can be found in the following Presentation: Jira Training material
YPM Issue types
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.
Epics are large bodies of work that need to be completed over several sprints or over a longer period of time.
Deliverables are generic output that is similar and required for each project and epic (FD, TD, HLD)
Test If needed, the deliverable for testing is moved to Issue type Test upon working on the issue.
Enhancement
The High Level Design (HLD) and Functional Design (FD) are always linked to the Project YPM-Issue (not Programme!)
The Technical Design (TD) can be done under the project (single application), but will be registered under the EPIC YPM-Issue.
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 , 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
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.
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).
Any work that can require a deployment uses the "Development" workflow:
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:
Epics have three additional statuses for Product Owners to prepare the work:
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:
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.
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.
J-sox compliance
YIS: DoD projects
When closing an item, it is mandatory to full the field "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. 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:
- PBI created
- User story defined
- Acceptance criteria defined
- Refinement & estimation done
- Ready for sprint
We find that most teams follow similar steps, so should be able to make use of this field.
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.
This way it's easy to see whether PBI's are ready for sprint:
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:
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:
More complex Jira features
...
Add-ons used by Information Systems
- Version manager Version manager for Jira plugin limits rights for all version managers to this specific functionality without the need for administer Jira-project permission.
- Status Time Free Easy reporting on how long an issue has remained in a specific status.
...
Overview
Content Tools