Ways of Working - 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.

This should be carried out following a group exercise (Product Owner group, along with Matt and probably Chris too (to make sure we don't leave out Ops requirements for TIS).

The suggested approach is as follows:

New requirements & Feature development

Develop and adhere to an overall screen flow - based on desired site mapping
Adhere to components based on UX, which would be linked to the screen flows: Programmes, Posts, People, Placements etc

Create and link Epics
Create and link Stories to Epics
Create and link stand alone Tasks to Stories or create Sub-tasks linked from Stories
Design TBD
Field validation should be created and linked to Stories~~/Tasks~~ where relevant
Data analysis should be conducted to ensure that we have the data and it supports the design via Metabase and/or in conjunction with Data leads - outputs can be added to the ticket(s)
Relative Business Values assigned
Estimate of complexity given

Ensure that all stories contain the relevant items from step 2 (and justification if not)

	Artefact Type	Description
1	Component / Theme	large area of work that impacts multiple teams / roles will span multiple sprints impacts FE & BE and potentially other areas should describe the area(s) of functionality in scope
2	Epic	focused area of functionality that impacts multiple teams / roles may require several iterations impacts FE & BE and potentially other areas should describe the focused area of functionality in scope
3	Story	specific functionality that impacts a single team or role (I don't think that this is a valid descriptor for a Story) ~~may still~~ will only require one ~~or more~~ sprints to resolve (this is a core fundamental of Scrum. If a Story is too big to be completed in a Sprint, it is by definition an Epic) impacts FE & BE and potentially other areas should describe the agile story including ~~should include~~ a statement of business benefit (consider using: As a [specific customer], I want [requirement], So that [Business benefit / opportunity cost]. Also 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 overall (Strongly consider the BDD structure – Given [current state of the system], When [change proposed in the Story], Then [expected outcome] - as this enables easier Test script creation) should include links to the field validation & data analysis should describe work around (if applicable), relevant red line dates & H / M / L rating in advance of Sprint Planning, should include a relative Business Value (the more granular the relative BV the better - P1-9 for example, using the spreadsheet calculator to help). As the team shrinks, over coming months, we need to be more focused on what to work on when - everything being a P1 is not helpful. either before Sprint Planning, or during it, discussions with relevant devs, should also result in an estimate of complexity (currently we loosely use T-shirt sizes: XL, L, M, S, XS, but could move to the more standard Story Points, an applied Fibonacci scale: 1, 2, 3, 5, 8, 13, 20 ,40, 100). Ultimately, we could consider determining Priority from these two metrics (in the linked article, where he refers to "time" or "urgency", read "Effort") e.g. 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. And either something with high BV, but high effort, or something with low BV but low effort becomes a middling priority Story.
4	Task / Sub-task	very specific task related to functionality that impacts a single team / role and that directly contributes to completing a Story - i.e. all work carried out should be linked to a Story) ~~should~~ must be manageable in 1 sprint (as a Task / Sub-task contributes towards a Story, and a Story must be achievable within ) impacts FE or BE and potentially other areas should describe what functionality is should include ~~acceptance criteria~~ associated unit test specific to task
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.

Bugs

Where this might differ is where Bugs are raised concerning existing development, in this scenarios TBD. However, adoption of assigning BV and Effort (and potentially priority) to BAU / Bugs means that the above approach continues to work well.