Product Refinement

Once the MVP product has been delivered, more focus can be given to product refinement - encouraging a more consistent and robust approach. This approach is by no means exhaustive, but should act as a guide to what "full" refinement of the TIS product and features looks like. It should also be a collaborative process, working closely with the Ops, UX/UI, Devs and stakeholders as necessary. The suggested approach is as follows:

New problems / problem statements needing solution development

Develop and adhere to an overall user journey - based on desired site mapping
Adhere to components based on UX, which would be linked to the user journeys: Programmes, Posts, People, Placements etc
- Create and link Epics
- Create and link Stories to Epics
- Create and link Sub-tasks to Stories (these could be UI, FED, BED, Testing, Ops or other functional Sub-tasks needed in order to complete the Story)
- Field validation should be created and linked to Stories where relevant
- Data analysis should be conducted to ensure that we have the data and that it supports the design
- Relative Business Values assigned
- Estimate of complexity given
Ensure that all Stories contain the relevant items from step 2 (and justification if not)
Functional walk through with Ops and Dev teams

	Artefact Type	Description

	Artefact Type	Description
1	Component / Theme	large area of work that will usually impact all users will span multiple sprints will impact all functional areas (UI, FE, BE & Ops) will describe the area(s) of functionality in scope
2	Epic	focused area of functionality that impacts multiple users will require several Sprints to complete will usually impact all functional areas (UI, FE, BE & Ops) will describe the focused area of functionality in scope
3	Story	specific functionality that may only impact a single user type or role must be achievable within a single Sprint will usually impact all functional areas (UI, FE, BE & Ops) describes the user story including a statement of business benefit Use: As a [specific customer], I want [feature], So that [business benefit / opportunity cost]. Consider creating a Loom video of the current system, such that when compared with the Loom video of the completed Story, the ticket can be seen to be complete, and therefore confidently moved to 'Done' should include acceptance criteria Use the BDD structure Given [current state of the system], When [user carries out an action], Then [expected outcome, showing change proposed in the Story] This enables easier Test script creation include links to the field validation & data analysis describe work-around (if applicable) in advance of Sprint Planning, should include a relative Business Value (the more granular the relative BV the better - scale of 1-9 for example, using the spreadsheet calculator to help). either before Sprint Planning, or during it, discussions with relevant devs (via one or more backlog refinement sessions), should also result in an estimate of complexity currently we Story Points, an applied Fibonacci scale: 1, 2, 3, 5, 8, 13, 20 ,40, 100. we can then determine Priority from these two metrics (in the linked article, where he refers to "time" or "urgency", read "Effort") - BV * SP = Priority E.g. Something of very high value to the business and very low effort to achieve becomes the top priority. Something of low BV, and a high effort to achieve becomes the lowest priority. Something with either high BV, but high effort, or something with low BV but low effort becomes a middling priority Story. I like this article too: https://www.scrum.org/resources/blog/10-tips-product-owners-business-value.
4	Sub-task	very specific Sub-task related to developing the feature detailed in a Story must be manageable in 1 sprint (as a Story must be achievable within a Sprint, then a Sub-task must also by definition be achievable within a Sprint) will usually impact a single functional area (UI, FE, BE & Ops) describes what the code development unit is must include associated tests
5	UX/UI design	TBD
6	Field validation	listing of relevant fields, validation, sections, error messages per component / theme rules should be validated with Data leads
7	Data analysis	extract of relevant data from Intrepid DR (via metabase) flag fields that should be in TIS and/or NDW validate with data leads

Once this checklist has been met, they can be discussed with the Development team for a smooth transition across to implementation. Any further additions can be made on an ad-hoc basis.

BAU / Bugs

BAU / Bugs are raised concerning existing development. They will be raised in the same way as a Sub-task is created - as a child ticket of its parent Story. Similarly, assigning Business Value and Effort (and therefore Priority) to BAU / Bugs means that they can be aligned with ongoing development. For example, a Bug that is preventing a user from using a significant part of the system should be clearly marked as a very high Priority piece of work, whereas a live user requesting a new feature for the TIS app that provides little value to few users should be clearly marked as a very low priority. This way, developers simply need to work their way through the Prioritised list of tickets in Jira rather than having to make any value judgements themselves regarding relative priority of BAU / Bugs / Stories.

The following should be included within Bug type tickets (and should be communicated to users and the service desk)

Title
Summary of the problem as stated by user / reporter
Relevant screenshots and/or Loom videos
Steps taken by user / reporter
Environment
User's / reporter's name & location
Component theme / epic / story link

Ideally, if the problem cannot be replicated, the reporter should be contacted for further to confirm whether it is down to user error or they have missed some detail when reporting the issue

These can be used to discuss with the Devs (following stand up), with a view to:

confirm all necessary information supplied;
confirm priority; and
clarify effort.

Helpful reading on bug definition:

https://github.com/deegree/deegree3/wiki/Bug-Report-writing-Guidelines

https://github.com/qTox/qTox/wiki/Writing-Useful-Bug-Reports

Story Completion 'Done'

On completion of Sub-tasks, Devs are to add to the Story / Bug the Git summary that they write when work is complete.
Devs initiate a PR request, and assuming their code passes all tests, the code is committed to the DEV environment and marked in Jira as 'Ready for release'.
The next release that takes place deploys the code to the STAGE environment.
PO group test functionality in STAGE, against the story (if it's passed all unit and BDD tests, this should just be a simple spot-check health test).
Once the next deployment takes place from STAGE to PROD, all Stories marked as 'Ready for release' in Jira will be marked as 'Done'.
If a Bug is raised against a Story that had previously been marked as 'Done', that Story should be marked back as 'To do' and the Bug linked to it.