| 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
...
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"
Warning Signs / Red Flags
The following may not always be a bad thing, but they can indicate an issue that can be further broken down
- 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
...
- 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
...