On Parents (Epics, Initiatives, etc)
Clearly define different parent types.
Examples: Epics are designated as new feature and work on them should be timeboxed to 30 days to encourage refinement and avoid overinvestment without a check-in. Initiatives are used to group and categorize multiple epics for reporting purposes.
Why? Set org-wide expectations on how use tooling, promotes good processes, and improves reportability across departments.
Do not have stories, tasks, etc go up to two or more of the same types of parents.
Why? Causes duplication when reporting on category information for epics or initiatives. Allstacks gives credits to all parents of the same type a single story rolls up to.
Use Target Start and Target End dates.
Why? Target Start date allows your teams to monitor scope creep. Target End dates allows your team to see how how likely they are to hit dates based on the work’s current scope and historical focus.
Add categories to your parents:
We recommend using single select fields for best results.
Examples: “Is Capitalizable?” (Yes, No, Review), “Investment Type” (New Feature, Tech Debt, Customer Commitment, Bugs/Defects, etc.)
Why? Allows you to see total development team investment spent on different categories for executive leadership. Also used for understanding resource allocation and availability to work on different investments in the future.
On Bugs & Defects
Track internally vs externally found bugs and defects.
Why? Allows your team to determine if bug rates are degrading consumer confidence in your platforms/products. Also utilized to determine SLAs.
Track defects pre-production or in-production.
Why? Defects found in QA/pre-production should be celebrated and utilized for coaching the engineering team. Defects found in production is helpful for tracking SLAs and for metrics like DORA.
Utilize Priority/Severity (and default these values to empty to avoid medium priority without thought):
Why? Priority is a great indicator of quality impact and urgency. A common definition across the organization improves quality reporting at the organization-level.
Using Resolutions / Statuses
Utilize, at a minimum, a “Done” status, and a “Won’t Do” status for ALL issue/work items types, including parents.
Why? Allows for much cleaner reporting for all metrics. Cleans out outliers. You can also report investment on work started but never completed.
Create common definitions for day to day work item/issue types AND timebox all of them to two weeks / a sprint duration for ALL teams.
Why? Allows consistent reporting within and across teams. Timeboxing encourages refinement and avoids over-investing.
Examples:
Stories: New feature work. Written from the end-users perspective.
Tasks: Maintenance or non-code work.
Bugs/Defects: Error correction and handling.
Spikes: Investigatory efforts. Typically timeboxed to a couple hours or days at most.
Sub-tasks: Smallest component of work, always the child of a story, task, bug, or spike. Always timeboxed to under two days to encourage refinement and work understanding.
Consider Up-leveling Your Issue/Work Item Workflows
Statuses to consider:
New
Product Requirements
Ready for Refinement
Refined - Ready for Dev
In Dev
Waiting for code review
Code Review
Waiting for QA
QA
Pre-Release
Done/Released