Page History

...

• Type: Issue type used, see list under YIS Issue types
  
  
• Priority: By default issues in YIS are set to priority Medium
  
  
  
• 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.
  
  
  
• Requirement status: The requirement test status by version or test plan, is used by XRAY and applicable for issue type Story and Change request.
  
  
  
• 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.
  
  
  
  
• Yamaha Team: Yamaha Team is a single select drop down field which is required for all issue types used in YIS. 
  

  

  This field includes 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 18/07/2023:
  
  
  

  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.

  

  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
  
  
  
  

• 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.
  
  The generalized DoR steps are:
  1. PBI created
  2. User Story defined
  3. Acceptance criteria defined
  4. Refinement & estimation done
  5. Ready for sprint
  
  
  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.
  For this reason, it is expected that this field will become mandatory across all YME projects in Jira and for all teams.
  When closing a Story, Bug or Defect, it is mandatory in YIS to fill the field "DoD projects":
  
  
  
  
• Design Review: Optional field activated on Epic, Story,  Bug 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.
  
• 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
  
  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
  Done	Done
  Done Deployment	Done - Deployment
  Canceled	Canceled

   

• 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.
  
  
• Phase: Indication in which phase the YNS project item is. (Issue type Epic, Story,Task, Subtask)
  
• Workstream:  EU workstream for YNS (Yamaha Next Stage) Project (Issue type Epic, Story,Task, Subtask)
  
  
• Dependent Workstream:  EU dependent workstream for YNS (Yamaha Next Stage) Project (Issue type Epic, Story,Task, Subtask)
  
  
• 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.
  
• 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.
  
• 
  
• Partner Issue Key YME: Single text view only field,  automatically filled for issues synced between EUYNS ↔ YIS.
                                           Used for YNS project reporting.  
• % Completion: Completion percentage for YNS work.

...

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

Image Removed

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

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 AddedImage Removed

These workflow steps are intended for:

• BacklogTo Do: work has not yet started (work can always move back to this specific status allows easy searching for open Epics);
• 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;
• Validation: PO/business validates that the functionality is as required, or provides feedback;
• 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 On Hold: Status only used for issues related to YNS, Workstream field is mandatory to be filled;
• Done: the work is completed without deployment needed; orwith deployments done on underlying items;
• Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete; or
• Ready for deployment: the work is done & documented, but deployment to production is needed;
Scheduled for deployment: deployment date is set;
Default transition for all teams: To Done Deployment
Image Removed
For some B2B teams a specific transition has been added to move an Issue to the next status, these options are only visible for users who can approve deployments and are included in group: YMEUACJiraB2BAppsDeploymentApprovers

• Image Removed
  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 Removed
  OMS Normal Deployment: used for Application-Module Ympact only, 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 INFRA-AS400 for move to Production. Via a B2B deployment Distribution list stakeholders are informed of the deployment.
Image Removed
OMS Interactive Deployment used for Application-Module Ympact only, 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 INFRA-AS400 for move to Production. Via a B2B deployment Distribution list stakeholders are informed of the deployment.

• Done deployment: the solution is available and working on production.

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.

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

Image Removed

• 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;
• 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.

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

Epics focus on Product Owners preparing the requirements:

Image Removed

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:

Image Added

These workflow steps are intended for:

• Backlog: 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;
• Validation: PO/business validates that the functionality is as required, or provides feedback;
• On Hold: Status only used for issues related to YNS, Workstream field is mandatory to be filled;
• Done: the work is completed without deployment needed; or
• Canceled: No further work will be done on this issue, it is not required anymore or has become obsolete; or
• Ready for deployment: the work is done & documented, but deployment to production is needed;
• Scheduled for deployment: deployment date is set;
  Default transition for all teams: To Done Deployment
  Image Added
  
  For some B2B teams a specific transition has been added to move an Issue to the next status, these options are only visible for users who can approve deployments and are included in group: YMEUACJiraB2BAppsDeploymentApprovers
  
  • 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, 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 INFRA-AS400 for move to Production. Via a B2B deployment Distribution list stakeholders are informed of the deployment.
  • Image Added
    OMS Interactive Deployment used for Application-Module Ympact only, 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 INFRA-AS400 for move to Production. Via a B2B deployment Distribution list stakeholders are informed of the deployment.
    
    
• Done deployment: the solution is available and working on production.

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.

YIS 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 four-step Workflow

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

Image Added

• 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;
• 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 four-step Workflow, except that it pre-fills the Yamaha Team entry from its parent.

Image Added

Image Removed

• 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 Workstream and Final Decision are mandatory to be filled before closing a Decision. 
• 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.

Enable Story includes Expert and Manager approvals of the design:
Image Removed

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

YIS Issue creation

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

...