Page History

...

Project YIS is a Software delivery Project.

YIS IssuetypesIssue types

YIS: Scrum Issue Type Scheme contains the following Issue types:

...

Items in YIS project build on theProgrammes orProjects created in YPM. More detailed information about YPM setup can be found here: Jira training for Portfolio Planning.
AnEpic should always be linked to one of these, so it is clear which strategic initiative it's part of.

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

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

ASub-task is task is an activity that needs to be performed to complete a higher-level issue type. It's always part of another issue type.

...

At the same level as Story, other Product Backlog Items exist with slightly different meanings:

ABug is a broken feature found outside of sprint;

A Change Request is a change to an existing feature, requested during UAT;

ADefect is a broken feature found during UAT;

ASpike is a Proof of Concept or other research required to prove the feasibility of a solution;

ATask is a Non-Functional Requirement, work in software development that brings no value to business yet is necessary (for example: code refactoring);

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

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

ATest describes a single test scenario;

ATest Execution reports the execution of a Test;

ASub Test Execution represents sub-task tests executions;

ATest Plan is a container for test cases, usually related to a single sprint;

ATest Set collects Tests that logically belong together, so they can easily be reused, for example for planning of UAT.

...

Story example:

• Type: Issue type used 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.
  
  
  
• Solution Group : This field is used to select a single department that the Yamaha Team falls under. Based upon this  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.
  
  
  

• Application-Module: Select list of applications (products) and modules (programs). 
  
  

• 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 01/01/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, 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:  is used to track the intended release date aligned with stakeholders.
  
  
• Ticket groups: Used to group stories and bugs under a YPM Programme. 
  
  
  

• Story Points: used to estimate the complexity, effort, and risk inherent to the story. Story Points field available for issue type Epic, 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.
  When closing a Story, Bug or Defect, it is mandatory to full the field "DoD projects":
  
  
  
  
  
• Installation instructions: used by some teams to store details for deployment, for example if configuration is required or run a SQL on production system. Optional field.
  
• Status: Workflow status summary.
  
  
• Resolution: Resolution is set automatically when an issue is closed.
  
  
• 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.

...

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

Image Modified

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

Image Modified

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

Image Modified

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

Epics have three additional statuses for Product Owners to prepare the work:

Image Modified

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

YIS Issue creation

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

...