| 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. I like this article too: https://www.scrum.org/resources/blog/10-tips-product-owners-business-value.
|