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.
...
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.
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
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
Refined - Ready for Dev
In Dev
Waiting for code review
Code Review
Waiting for QA
QA
Pre-Release
Done/Released: 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.