Page History
...
Taxonomy YNS Issue Types
| ISSUE TYPE | USAGE |
|---|---|
| Capability | Highest level in YNSEU. Used to split the project in L1 processes. Capabilities can only be closed if underlying MILESTONES are closed! |
| Milestone | Second level in YNSEU. Used to divide the project to the level of Process delivery document (PDD) (L2,3,4). Milestones can only be closed if underlying FEATURES are closed! |
| Feature | Third level in YNSEU. Used to group bigger activities (mini projects) under a PDD. Features can only be closed if underlying EPICS are closed! |
| EPIC | Fourth level in YNSEU, but not residing as issue type there. EPICS reside under YIS and are meant for the power teams to do the work in. It is used to break up the features in to manageable iterations. EPICS are open for the maximum period of a quarter, and are used to plan QRP (quarterly release planning). EPICS only have 1 responsible team. Multiple teams working on a feature, means multiple EPICS. EPICS cannot be closed UNLESS the stories and tasks are completed. |
| Task | Part of an EPIC, usually there to record non-development work. Can only be closed after completion of sub-tasks! |
| Story | Part of an EPIC, usually there to record development work. Can only be closed after completion of sub-tasks! |
| Sub-Task | Part of a story or task, usually there to break up work in smaller pieces. |
| Decision | Stand alone issue type in YNSEU, used to record any decision we need to record and report upon. |
| Defect | A non-production related bug, coming from a unit or user test that needs fixing. |
| Bug | A production malfunction that requires fixing |
Display YNSEU Project structure
...
PLANS are setup based upon filters. For the YNSEU project, we filter upon:
| Field | Value |
|---|---|
| Workstream | EU XXXXX |
| Component | YNS |
| Team | Drop down list |
| Ticketgroup(s) | Optional, advised to use for QRP planning, managed by PO's. The options to use: QRP-Year-Q(uarter) |
These fields are expected to be filled out. If you forget either of them, you will not be seeing your issue in the roadmap overview.
...
Creating a link is done out of any issue type via MORE, LINK. Depending on the direction of the dependency you can select one of under mentioned link types.
Blocks (can be used for any issue type)
Incoming dependency: blocks
Outgoing dependency: is blocked by
Defect
Incoming dependency: defect of
Outgoing dependency: has defects
CREATE a confluence page link
It is very helpful to have documentation links out of issues to have quick material reference available. Eg. a functional spec should be tied to the story recording the activity.
You can make that link best out of the confluence page, in which you have to include a Jira ISSUE Link. Within Confluence, in the EDIT mode of a page, you can go to the + plus pictogram and use insert Jira Issue.
Type the YIS or YNSEU issue and confirm. After saving, it will collect the status of the referenced Jira issue and reflects that in a nice manner.
In the YIS or YNSEU issue, you will see a wiki link, which is a hyperlink to the confluence page.
YNSEU Issue creation
Users (licensed userand authorized users) can use the 
button anywhere in Jira from the top bar.
...
Issues can also being created via the Board or backlog. Detailed instructions can be found in Jira training Basics - Issue Creation.
YNSEU Boards
Communication
It is key that communication on topics is consolidated to the issues covering them. This is to secure no information is lost, and we have a complete history in one place.
Within the issue types we use within the YNSEU and YIS project, we use the COMMENT functionality for communicating to the stakeholders (watchers, reporter, assignee) or even a particular person, not being in the stakeholder list (condition: that user must have Jira licenses)
You can pin-point communication to a particular recipient by using the "@" sign.
Overview
Content Tools