Versions Compared

Old Version 89

changes.mady.by.user Bianca van der Meer

Saved on

compared with

New Version Current

changes.mady.by.user Bianca van der Meer

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Never worked with Jira before? No problem. Please first read the Jira training Basics page.
This chapter is part of is part Jira training for Information Systems, below the Jira setup for Information Systems - Yamaha IS Projects (YIS) is explained.

Project YIS is set up as a single space to allow Information Systems and Business to align on an Agile way of working, as part of the Agile Transformation.

...

Below two sections are most relevant for YIS: 

Note

Per The Backbone Sync has been stopped between YIS and YNSEU. A new project structure and way of working has been setup in YNSEU.
Eventually Yamaha Next Stage Project (EUYNS) will be phased out.

Yamaha Next Stage Project (YNS)

Yamaha next Stage project within YME Jira is managed within two Jira Projects, YNSEU and YIS.
High Level planning for the YNS project and Decisions are logged under project YNSEU.
Team work is all done within project YIS and the following issue types are supported for YNS Project planning: Epic, Story, Bug, Defect, Task and Sub-Task.


For the project tracking of YNS specified fields have been introduced to YIS.  Examples are fields Workstream and Dependent workstream. See the full list under chapter YNS Specific fields
Also Workflow for Story, Bug, Defect includes an additional status like 'On Hold' that can only be used specifically for YNS related issues.
Validation to use this status is that the Workstream field cannot be empty.

Epics related to the YNS project are linked to a Feature in the YNSEU Project.
More information about the YNS Project Project structure and YNSEU Project can be found here: Jira training for Yamaha Motor Next Stage (YNSEU)

...


Explanation per issue type used in YIS:

AnEpic is is a large feature, that is broken down into its component Stories/Tasks etc. by a scrum team.

AStory is a feature that can be tested separately, and is part of an Epic.

...

For testing addon Xray is used, the following issue types exist. These are used solely by testers, to plan their work;

APrecondition 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;

ATest describes a single test scenario;

...

  • YIS Field Configuration, this is used by default
  • YIS sub-task Field Configuration, used by Issue type Subtask.

YIS

...

Mandatory Fields

Image Added

Type:  Automatically filled                                                                                                                                                                                     

Priority: By default issues are set to Low

Yamaha Team: Determine responsible  team who will be working on this issue and is required to make it visible on a Board/ Dashboard/ Plan

Resolution: Required when issue is closed

Fix Version/s: required for Story or Enable Story when status is set to Done Deployment




YIS Specific Fields

Example Fields overview for Issue type Story,  Sub-task:

Image Added   Image Added

All used issue fields in YIS are explained below:

  • Type: Issue type used, see list under YIS Issue types

  • Priority: By default issues in YIS are

...

Example Fields overview for Issue type Story,  Sub-task:

Image Removed   Image Removed

All used issue fields in YIS are explained below:

  • 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 Division. 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. Issue created
    2. Requirements defined - the use case & acceptance criteria are clear, why we want to do this and how we will test;
    3. Prioritized against other work - the product owner has ranked the items in priority;
    4. Refinement & estimation done - developers understand the item and have added estiamation;
    5. Ready for work - any dependencies are managed and the team can start the development.

    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.
    When closing a Story, Bug or Defect, it is recommended to fill the field "DoD projects".



  • Design Review: Optional field activated on Epic, Story,  Bug, Defect 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.

    StatusResolutionDescription
    DoneDoneThe task/configuration has been completed.
    Done DeploymentDone - DeploymentDeployment has been completed.

     

  • For Status Canceled a resolution can be selected when the issue is going to be closed

    StatusResolutionDescription
    CanceledCannot ReproduceThe problem cannot be replicated or is not clear.
    CanceledDuplicateThe issue is a duplicate of another issue.
    CanceledWon't DoThe issue will not be addressed, often used for non-issues or low-priority items, or the business has decided not to implement the requested feature.
  • 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.

  • 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.
  • Target start: Planned start date when a team will start working on the issue. Used for Advanced Roadmaps plans.
  • Target end: Planned end date when a team will complete the work on the issue.  Used for Advanced Roadmaps plans.
  • 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. Applicable for issue type Epic,  Story, Enable Story, Task, Bug, Defect, Spike, Change request.
  • 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. Applicable for issue type Epic, Story, Enable Story, Task, Bug, Defect, Spike, Change request.


YNS Specific fields
Anchor
YNS_Specific_fields
YNS_Specific_fields

Applies to YIS Issue types:  Epic, Story, Bug, Defect, Task, Subtask

  • Component/s: Component YNS is mandatory to indicate that an issue is part of the YNS project. In YIS  Component YNS  is automatically when a field workstream is set or changed.Component YNS is mandatory to indicate that an issue is part of the YNS project. 

    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: Image Added

  • Phase: Indication in which phase the YNS project item is. 

  • Workstream:  EU workstream for YNS (Yamaha Next Stage) Project 

  • Dependent Workstream:  EU dependent workstream for YNS (Yamaha Next Stage) Project 

  • % Completion: Completion percentage for YNS work.
  • Partner Issue Key YME: Single text view only field,  automatically filled for issues synced between EUYNS ↔ YIS. Used for YNS project reporting.  

  • Test Phase: Single select drop down field to indicate test phase of a defect. Only applicable to issue type Defect.
  • Defect CategorySingle select drop down field to indicate the category. Only applicable to issue type Defect.

YIS Workflows

This project contains four workflows, with the distinction being made whether an item contains a software release (development workflow) or not (four step workflow).

...

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

image2022-12-2_14-59-56.png

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: Image Modified

Issues can also being created via the Board or backlog. Subtasks can being created via the original issue. Detailed instructions can be found in Jira training Basics - Issue Creation.

For a Story automatically a description is pre-filled.
Image Modified

YIS BUG creation

Bugs can directly created via the button, see more detailed explanation above.
When a Bug has been registered via a Servicedesk ticket (SD) then automatically a YIS Bug issue can be triggered via SD workflow transition Bugfix-YIS.
Automatically the SD-issue will be linked to the YIS-issue and changes to status Awaiting development. Once the Bug has been resolved the reporter and requested participants can be informed via the SD-issue.  
Only users with Bugfix creation permission are able to use this option. 
For SD workflow see documentation under: Jira training for Yamaha Applications Support Desk (SD) - Software Delivery BUG/Incident issue creation via SD

...