| Table of Contents |
|---|
Introduction
I have previously written a lightning talk introducing some helpful patterns for writing JIRA tickets. It introduces some terminology, as well as what should be expected from a fully-detailed ticket.
The purpose of this document is to supplement those definitions with examples of breaking down larger work items to increase transparency into the process and maintain forward momentum.
Hints / Steps for Breaking Things Down
- Read the Epic carefully - try to visualize the full picture of what it would need to provide. Are there steps needed that are not covered by the existing tickets?
- Read an issue that you suspect can be broken down - watch out for any Red Flags (listed below)
- If you identify a Red Flag, try to think of how to make that part of the issue standalone - NOTE: it is ok for issues to form a hierarchy or to depend on one another
- Write a new Story based on the subset of work you've identified, and then link it back to the original ticket
- Check the original ticket again to remove any text / feature that is now covered by the new ticket(s)
NOTE: If you do manage to tease out one or more new issues, link it back to the original by clicking Link Issues and choosing "split from" or "split to"
...
- Singleton Epic - an epic with only a single Story is either too small to be an epic or too large to be a story
- Not enough details - very short ticket text with a very high estimate makes us wonder where those extra points are coming from
- Commas / Conjunctions (e.g. and / or / but) - can indicate a pause or change in focus
- "also" / "as well" / "includes" / "including" - extraneous things that can usually be split into separate tickets sometimes use these types of modifiers
- a single Story requires changes to multiple repositories - typically Stories can be broken down such that they only need to change 1 repo at a time (if they can't, this may indicate coupling or issues maintaining the "separation of concerns")
- A clear disconnect or confusion between what was asked for in the ticket vs what was suggested by leadership - this indicates that one or more people did not understand the full scope of the work requested
- ... and many more
...
Case Study: Improve Extractor Catalog
See https://digitial-product-engineering.atlassian.net/browse/SIMPL-115
...
- Expand admin-only Extractor Catalog to make it public
- Add additional information to this view (e.g. version, rating, comments, etc)
- NOTE: While there were lots of unanswered questions, this discussion did match up fairly well with the original ticket text
...