Table of Contents

Introduction

Never worked with Jira before? No problem. Please first read the Jira training Basics page.
In this chapter below the Jira setup for 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.
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.

Yamaha IS Projects (YIS) 

Project YIS is a Software delivery Project.

Users can create new issues via the Image Added button in the top bar. 

YIS Issuetypes

...

YIS: Scrum Issue Type Scheme contains the following Issue types:
Image AddedImage Removed

Issue types have a hierarchy to them:

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

An  Image AddedEpic is a large feature, that is broken down into its component Stories by a scrum team.

A A Image AddedStory is a feature that can be tested separately, and is part of an Epic.

A A Image AddedSub-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:

A Image AddedBug is a broken feature found outside of sprint;

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

A Defect is a broken feature found during UAT;

A Image AddedSpike is a Proof of Concept or other research required to prove the feasibility of a solution;

A Image AddedTask 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  addon Xray is used, the following issuetypes issue types exist. These are used solely by testers, to plan their work.:

A Image AddedPrecondition 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 Image AddedTest describes a single test scenario;.

A Image AddedTest Execution reports the execution of a Test;.

A Image Added Sub Test Execution represents sub-task tests executions.

A Image AddedTest Plan is a container for test cases, usually related to a single sprint.

A Image AddedTest Set collects Tests that logically belong together, so they can easily be resusedreused, 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).

Image Removed

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

Image Removed

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:

Image Removed

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

Image Removed

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

YIS Issues overview

YIS Specific Fields

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.

...

Additionally, on Kanban boards, closed items will disappear from the board once a fix/version is closed, not earlier.

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:

1. PBI created 
2. User story defined
3. Acceptance criteria defined
4. Refinement & estimation done
5. Ready for sprint

We find that most teams follow similar steps, so should be able to make use of this field.

Image Added

N.B. This is an optional feature. Set the field manually in refinement sessions, in case that makes sense for your team.

DoD projects

When closing an item, it is mandatory to full the field "DoD projects":

...

N.B.: Jira COP wishes to limit the field to only being mandatory when a release is involved, this is a planned improvement.

...

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:

1. PBI created 
2. User story defined
3. Acceptance criteria defined
4. Refinement & estimation done
5. Ready for sprint

We find that most teams follow similar steps, so should be able to make use of this field.

Image Removed

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.

Image Removed

This way it's easy to see whether PBI's are ready for sprint:

...

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

Image Added

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

Image Added

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:

Image Added

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

Image Added

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.

YIS Boards

YIS works with 3 template boards:

...

Good to know: YIS project uses a template Scrum and Kanban board, which has the same configuration across teams.

YIS Product Owner board

For Product Owners (PO's) who want to collaborate across teams, we can set up a Product Owner Board.

...

A PO board follows Epics across the board in a Kanban flow, using the YIS Epic statuses:

YIS Scrum template

Within YIS all scrum boards use the same template, with the following configuration features:

...

• WIP limit set to team size: distribute the amount of developers over In Progress / Review columns, and the amount of testers over Ready for Test / In Test columns. The BA or PO validates items with status UAT.

YIS Deployment Board

The work done in sprints ends when a PBI is either "Done" or "Ready for Release" in the item workflow. All items that require a deployment are next shows on the Deployment Board.

...