Document our use of epics and issues
Document our use of epics and issues:
- Sprint-ready issues should specify small, well-contained tasks.
- Issues which unpack into sets of smaller issues within the same project should be treated as "mini epics" and have sub-issues attached as related issues.
- Issues which unpack into sets of issues across projects should be created as epics. Epics should be created as high up the hierarchy as makes sense since issues and sub-epics which are not within an epic's group cannot be added.
- Long-term plan epics for each of our products should be created at
uis/devops
level. - Epics representing live workstreams should be added to the live workstream epic.
Epics are used to track multi-sprint work items which span multiple projects. Multi-sprint issues which within a single project should use tracking issues with related sub-issues for the simple reason that epics cannot be created on a single project.