Versions Compared

Version Old Version 6 New Version Current
Changes made by

Former user

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 necessaryThe . The suggested approach is as follows:

New

...

problems / problem statements needing solution development

  1. Develop and adhere to an overall

...

  1. user journey - based on desired site mapping

  2. Adhere to components based on UX, which would be linked to the

...

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

  2. Ensure that all

...

  1. Stories contain the relevant items from step 2 (and justification if not)

  2. Functional walk through with Ops and Dev teams


Artefact Type

Description

1

Component / Theme

  • large area of work that

impacts multiple teams / rolesshould

  • will usually impact all users

  • will span multiple sprints

  • impacts FE & BE as well as other areas

    • 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 

    • that impacts multiple

    teams / roles

    • users

    may

    • will require several

    iterationsshould

    • Sprints to complete

    • will usually impact all functional areas (UI, FE, BE & Ops)

    • will describe the focused area of functionality in scope

  • impacts FE & BE as well as other areas

    • 3

    Story

    • specific functionality that

    impacts

    • may only impact a single user

    team

    • type or

    user 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:

    • 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


    •    I want [

    requirement

    • feature],

    So


    •    So that [

    Business

    • business benefit / opportunity cost].

    Also consider


    • 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


    • Use the BDD structure

    – Given


    •    Given [current state of the system],

    When [change proposed in the Story], Then


    •    When [user carries out an action],
         Then [expected outcome

    ] - as this

    • , showing change proposed in the Story]
      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 relativeBusiness Value (the more granular the relative BV the better -

    P1
    . 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 (via one or more backlog refinement sessions), should also result in anestimate 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

    )determining

    • .

    Ultimately, we could consider
    e.g. BV

    •  - BV * SP = Priority

    .


    • E.g.

    Something


    •    Something of very high value to the business and very low effort to achieve becomes the top priority.

    Something


    •    Something of low BV, and a high effort to achieve becomes the lowest priority.

    And either something with

    4

    Sub-task

    • very specific Sub-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 

    • developing the feature detailed in a Story

    • must be manageable in 1

    sprint 

    • sprint (as a

    Task / Sub-task contributes towards a

    • Story

    , and a Story

    • must be achievable within a Sprint, then a

    Task / should include acceptance criteria associated unit test specific to task

    • Sub-task must also by definition be achievable within a Sprint)

  • impacts FE or BE and potentially other areas
  • should describe what functionality is

    • 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

    Where this might differ is where BAU / Bugs are raised concerning existing development, however, adoption of . 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 potentially prioritytherefore Priority) to BAU / Bugs means that they can be aligned with ongoing development. For example, a Bug that the above approach continues to work wellis 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 during the 10am slot (following stand up), with a view to ( i ) :

    1. confirm all necessary information supplied

    ...

    1. ;

    2. confirm priority; and

    ...

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

    ...

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

    ...

    1. .

    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.