Versions Compared

Key

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

...

ProjectKeyProject type and Purpose
SD

Jira Service management - Incident management including Customer Portal

B2B-Apps - BABA

Software delivery  - Cognos, TM1, Cubes

B2B-Apps - LogisticsBLSoftware delivery  delivery - YLS, SYS2000, Witron
B2B-Apps - YmpactYMSoftware delivery - YMPACT
B2C-AppsB2CSoftware delivery  - various products used by B2C/EPAM team(s)
Change Advisory BoardCABSoftware delivery - management approval
YamahaISprojectsYISSoftware delivery -  Agile teams
Yamaha Portfolio BoardYPMSoftware delivery - Portfolio/Project planning 
Yamaha Motor Next Stage ProjectEUYNSSoftware delivery - Yamaha Next Stage (SAP/Informatica)

...

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

Image Removed

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.

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

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

Image Removed

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

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

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

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.

Image Removed

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.

YIS: DoD projects

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

Image Removed

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:

  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:

Image Removed

YIS Boards

YIS works with 3 template boards:

...

ProjectKeyProject type and Purpose
B2B-Apps - BABA

Software delivery  - Cognos, TM1, Cubes

B2B-Apps - LogisticsBLSoftware delivery  - YLS, SYS2000, Witron
B2B-Apps - YmpactYMSoftware delivery - YMPACT
B2C-AppsB2CSoftware delivery  - various products used by B2C/EPAM team(s)
YamahaISprojectsYISSoftware delivery -  Agile teams

In due time, Information Systems teams working in Jira Software projects will be onboarded to the YIS project, so this can become our mutually agreed way of working for Software delivery.

Any team joining will be coached through the (Agile) transition and will be able to provide input on unique ways of working that will need to be integrated. Together we will make it a success.

For now, these Information Systems projects will keep on using their current of way of working. With time and proper preparation, they will migrate into YIS. 


Yamaha IS Projects (YIS) 

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.

Documentation can be found on the following page: Jira training for Yamaha IS Projects (YIS) 

B2C-Apps (B2C)

 Jira

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

Image Removed

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:

Image Removed

YIS Scrum template

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

  • Custom field "Business value" is used to estimate (in a fibonacci range) the value of that piece of development to the YME business.
    Something that cannot be used yet (partial development or a spike) has BV 0, while a development that benefits entire Europe might count as much as BV 13.
  • Custom field "DoR" is used to track the Definition of Ready, or PBI readiness for development.
  • Card colours show the stages:

Image RemovedImage Removed

  • The board contains quick filters to easily select only PBI's relevant for the specific person or meeting:

Image Removed

Image Removed

  • Board Columns are named for the story status, though as long as multiple projects exists other statusses are also shows in these columns:

Image Removed

  • "Days in column" is activated. Hovering over the dots shows the amount of days in column in text.

Image Removed

  • Custom field "Target release date" is available to track the intended release date aligned with stakeholders.
  • When closing an item, the "Resolution" is set. This field is cleared when an item is reopened.

YIS Kanban template

Within YIS all Kanban boards use the same template, with the same configuration features as the scrum template, and in addition:

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

Image Removed

YIS Deployment Board

More complex Jira features

...

SD-> B2C-Incident ticket creation

As discussed with Patrick a new functionality in Jira SD project has been created for B2C.

If a SD ticket is in progress a linked B2C-Incident ticket can now be created via Workflow-Create B2C-Incident button.

...