Before work is ready for development, any idea for software development is first vetted by the portfolio management, to understand whether the proposal is of strategic value to YME. Once it is agreed that the idea should be implemented, a selection of what to do first is made based on business case, priority, and urgency. This way we ensure that time is spent on the most valuable topics.
Issuetypes from YPM start with Programme in case of a large multi-quarter initiative, or start with Project in case of a large single-quarter initiative. A Programme can contain multiple Projects, just like a Project can contain multiple Epics.
An Epic represents high-level initiatives or bigger pieces of work in Jira that need to be broken down.
An Enhancement is a smaller, standalone improvement of existing functionality, that has strategic value on its own.
A Deliverable is used to capture the High Level Design and Low Level Design, created by architects as input for the development team assigned.
A Test is intended to capture UAT planning.
In due time it is expected that Epic, Deliverable, and Test will move into the development projects, away from Portfolio Planning.
This project contains four different workflows, which in some cases include a Project Review Board (PRB) or AWG approval flow.
The field configuration is shared between YPM and CAB projects. The screen configuration is unique to YPM and contains a great many fields on screen.
Upon request of PMO team a multi select field Yamaha team(s) for Issue type Programme and Project, Enhancement and Epic has been created.
This field replaces the old Team Yamaha field for these two Issues types. If assistance for a bulk update is required, please contact a Jira Administrator.
The Yamaha Team single select field is only needed to be filled for the creation of Deliverables or an Enhancement ticket. These issue types triggers a Development ticket creation in another Jira project like YIS, B2C, YM, BA, BL.
Team(s) can be selected via a drop down menu and pressing CTRL to select multiple teams.
When no values are set, select the edit button to add field values.
Upon request of Architect Working Group A User Picker field for Responsible Architect has been setup.
This field will be used by the Architect Working Group to select the Responsible Architect for Programme and Project.
When no value is set, select the edit button.
This field works similar as the Assignee field. When you start typing, suggestions will be made of matching users. Select the user to confirm your choice.
When set it will appear in the people section on the right hand side:
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.
A Story is a feature that can be tested separately, and is part of an Epic.
A Sub-task is an activity that needs to be performed to complete a higher-level issuetype. It's always part of another issuetype.
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 is ???
A Test describes a single test scenario;
A Test Execution reports the execution of a Test;
A Test Plan reports the execution of a Test Set???
A Test Set collects Tests that logically belong together.
This project contains three workflows, with the distinction being made whether an item contains a software release (development workflow) or not (four step workflow).
Epics have three additional statusses for Product Owners to prepare the work:
When closing an item, you are often prompted to fill in the mandatory field for Fix/Version.