Optimizing Your Project Management Tools for Use with Allstacks

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:
- 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.

Utilizing Start & End Dates

Start/end dates

How to define “start” - As scoped solidified

End as potential work done or released date

Common card type definitions

Capitalizable flag at epic level

Any other investment type information you want to have

ULT-Work Categorization

Common definition and size for epics / initiatives

Workflows: & workflow states (Jira - When is resolved) - If you’re going to add anything additional, you would add wait states