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