Versions Compared

Key

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

Current Configuration

Seko Pipelines (SPIP)

Issue Types in SPIP are

  • Epic

  • Development

  • Sub-task

  • IT-Help

All issue types contain the same issue type configuration and contain fields like “Stakeholder” specifically for the Pipelines project.

Screens

PIP: Jira Service Desk Issue Type Screen Scheme applied to all issue types

WMS (SWMS) and DCM (SDCM)

These need to share the same issue types and the same layouts

WMS (SWMS)

Issue Types in SWMS are

  • Bug

  • Epic

  • Improvement

  • IT Help

  • New Feature

  • Service Request

  • Service Request with Approvals

  • Support

  • System Configuration

  • Task

Screens

SWMS: JIRA Service Desk Issue Type Screen Scheme applied to all issue types

DCM (DCM)

Issue Types in SWMS are

  • Bug

  • Epic

  • Improvement

  • New Feature

  • Service Request

  • Support

  • System Configuration

  • Task

  • Testing Feedback

  • Sub-task SUB-TASK

Screens

SSC: JIRA Service Desk Issue Type Screen Scheme applied to all issue types

Required Configuration for new Seko Pipelines Project

Seko Pipelines (SPIP) - No change required

Issue Types in SPIP are

  • Epic

  • Development

  • Sub-task

  • IT-Help

All issue types contain the same issue type configuration and contain fields like “Stakeholder” specifically for the Pipelines project.

Screens

PIP: Jira Service Desk Issue Type Screen Scheme applied to all issue types

WMS (SWMS) and DCM (SDCM)

These need to share the same issue types and the same layouts

WMS (SWMS) - split this up into all except Epic with Epic as per Pipelines

Issue Types in SWMS (1)

  • Bug

  • Improvement

  • IT Help

  • New Feature

  • Service Request

  • Service Request with Approvals

  • Support

  • System Configuration

  • Task

Issue Types in SWMS (2)

  • Epic (like Seko Pipelines epic issue type)

Screens

New screen definition to address issue types above

DCM (DCM) - split this up into all except Epic with Epic as per Pipelines

Issue Types in DCM (1)

  • Bug

  • Improvement

  • New Feature

  • Service Request

  • Support

  • System Configuration

  • Task

  • Testing Feedback

  • Sub-task SUB-TASK

Issue Types in DCM (2)

  • Epic (like Seko Pipelines epic issue type)

Screens

New screen definition to address issue types above

...

Issue Type

...

Pipelines

...

WMS (2 schemes)

...

DCM (2 schemes)

...

Epic

...

New (as Pipelines)

...

New (as Pipelines)

...

New (as Pipelines)

...

Development

...

Pipelines

...

Sub-task

...

Pipelines

...

IT-Help

...

Pipelines

...

Bug

...

As Current

...

As Current

...

Improvement

...

As Current

...

As Current

...

IT Help

...

As Current

...

New Feature

...

As Current

...

As Current

...

Service Request

...

As Current

...

As Current

...

Service Request with Approvals

...

As Current

...

Support

...

As Current

...

As Current

...

System Configuration

...

As Current

...

As Current

...

Task

...

As Current

...

As Current

...

Testing Feedback

...

As Current

...

Sub-task SUB-TASK

...

As Current

Notes

Having discussed with the development team, the following issue types need to be removed, as shown in red on the table above:

  • IT Help

  • Service Request with Approvals

  • Testing Feedback

  • Sub-Task SUB-TASK

Current Configuration

Epics

Epics are a unit of functionality which can be spread over more than one sprint. They are split into user stories which make up the unit of functionality. Sometimes epics are also split so that they fit into a certain phase of the project making up the next viable sub-unit of functionality towards the final goal.

Epics have the workflow SPIP 2019 which is specifically for business use, ie. stakeholders can see where a unit of functionality is within the software development life cycle (SDLC).

...

User Stories

User stories are the business focussed user requirements for a piece of functionality and require a business-based approach which details the user requirements to fulfil the work as well as detailed information where necessary and acceptance criteria. This is the main crossover between business and technical work.

User stories have the workflow Indigina 2021 Story Level where the statuses reflect the stage of analysis for the work by the business based author.

...

Other issue types and sub-tasks

Other issue types which are not sub-tasks should probably have a workflow at user story level.

Subtasks have parents of other issue types, particularly user stories. They are development-centric only and have workflow Indigina 2021.

...

Scrum Based Agile Framework

There is a backlog and sprints.

The sprints are time-boxed developments where a certain amount of user stories are committed to be delivered.

The backlog is a non-exhaustive, continuous, prioritised list of requirements which describes the anticipated requirements system. Items are taken from the top of the backlog for each sprint as determined by the development team. It is best for the sprint items to be fully described, ie. ready for development, although there is no actual requirement in the Scrum framework for this status. In the real world however, knowing that something is fully described is important for developers to know what they are doing.

To that end, there are statuses prior to development which lend themselves to the status of the requirements elaboration. These are represented in the backlog as colours on the left hand side.

...

The key at the time of writing is as follows and is the same across all the projects:

...

  • Green is ready for development

  • Teal is almost ready, ie. needs to be “signed off” by development

  • Blue is business analysis in progress in order to prepare for checking by development

  • Orange is blocked by requirements or put on hold

  • Red is not even looked at from a Business Analysis perspective

The idea is that the business can see what state the tickets are in to get a better chance of knowing what needs to be worked on in order for developers to be able to get on with technical analysis and programming the requirements.