...
| 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 [change proposed in the Storyuser 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), 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 - 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 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. - 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 Task / 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 unit test 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
|
...
These can be used to discuss with the Devs during the 10am slot (following stand up), with a view to:
...