Versions Compared

Version Old Version 14 New Version Current
Changes made by

Andy Nash (Unlicensed)

Andy Nash (Unlicensed)

Saved on

Key

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

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

  1. Develop and adhere to an overall user journey - based on desired site mapping

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

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

  5. Functional walk through with Ops and Dev teams


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

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.

...

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:

  1. confirm all necessary information supplied;

  2. confirm priority; and

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

  1. On completion of Sub-tasks, Devs are to add to the Story / Bug the Git summary that they write when work is complete.

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

  3. The next release that takes place deploys the code to the STAGE environment.

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

  5. Once the next deployment takes place from STAGE to PROD, all Stories marked as 'Ready for release' in Jira will be marked as 'Done'.

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