Though Allstacks can be used with project management and source code tools with various configurations, we’ve gathered best practices below to further improve your experience with the platform.
On Using 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 Daily Work Item / Issue Types AND timebox all of them to two weeks / a sprint duration for ALL teams.
Set org-wide standards on how to use your engineering tools, including timebox expectations for each issue type.
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
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
Creating Card Type Definitions & Upper Time Bounds
Common card type definitions
Define the smallest increment of work
Subtasks?
Add spike card
Story/New Feature
Task, no code or repeatable
KTLO task vs bug
Bugs
Internal vs external field or separate issue type
Investment / Capitalizable Concepts at Parent Level
Capitalizable flag at epic level
Any other investment type information you want to have
Tech debt, etc.
ULT-Work Categorization
Can be variable at parent level
Common definition and size for epics / initiatives
Goal of any parent is an org-wide definition
Jira Issue Workflows & Azure Devops Work Item States
Workflows: & workflow states (Jira - When is resolved) - If you’re going to add anything additional, you would add wait states
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
Improving your issue workflows can provide valuable information, such as determining if there are bottlenecks in your handoff points between roles and responsibilities, understanding if your team is adequately refining work, and tracking if completed work has made it into your deploy cycle.
Statuses to consider:
New: Genesis state. Useful for tracking time since creation.
Product Requirements: Let’s users know that this issue is still owned by the product team.
Ready for Refinement: Waiting state. Product team has performed their initial story and requirements gathering and the issue is now waiting for the next technical refinement.
Refined: Issue is ready to be worked on by the engineering team.
In Development / In Progress: Issue is actively being developed against / worked on.
Waiting for Code Review: Wait state. Helpful for tracking code review capacity and pickup time.
Code Review: Actively in code review.
Waiting for QA: Wait state. Useful for tracking QA capacity and pickup time.
In QA: Actively being reviewed for accuracy and defects.
Pre-Release: Wait state. Has passed all checks but is not deployed.
Done/Released: Deployed or out of the team’s purview.