Ticket Tracking
Status: Accepted
Last Modified: 2023-07-11
Related Issue: #98
Deciders: Lucas Brown, Esther Oke, Sumi Thaiveettil, Sarah Knopp, Aaron Couch, Billy Daly
Tags: communications, sprint planning, agile
Context and Problem Statement
The project needs a system for tracking ongoing development work within the project, preferably as a series of tickets that can be organized into sprints. This system would both enable internal stakeholders to prioritize key tasks and assignments throughout the project and help communicate those priorities to external stakeholders.
The goal of this ADR is to evaluate a series of ticket tracking systems and select the one we will be using for the project.
Decision Drivers
Must Have
Ticket Tracking: Tickets can be organized into sprints and tracked as part of larger deliverables
Public Access: Without logging in, members of the public can see tickets that are being worked on
Public Requests: Members of the public can submit bug reports and feature requests and track how that work is being prioritized
Templates: The system supports default templates for different types of tickets which prompts the person creating the ticket for a specific set of information
Authority to Operate (ATO): The platform already must be authorized under the Grants.gov ATO (Authority to Operate) or ATO coverage must be requested
Reporting: Users can report on the following key metrics:
Sprint burndown -- % of tickets and/or points remaining over the course of the sprint
Deliverable burdown -- % of tickets and/or points remaining per deliverable over time
Sprint allocation -- # of tickets and/or points allocated to each team member per sprint
Sprint completion -- # of tickets and/or points created vs planned per sprint
Sprint velocity -- Average # of tickets and/or points completed per sprint
Lead/cycle time -- # of days between creation of a ticket and when that ticket is closed
Nice to Have
Level of Effort Estimates: Tickets can be assigned an estimated level of effort (e.g. story points, t-shirt size, etc.)
Custom Views: Users can create custom views for managing tickets with multiple layouts (e.g. kanban board, tabular, roadmap)
Custom Fields: Users can create custom fields and views to manage their projects
Automation: Users can automate basic workflows like adding and moving tickets, linking PRs to their originating PRs, etc.
Open Source: The tool used to manage and host the wiki content should be open source, if possible
Options Considered
Decision Outcome
We are planning to use GitHub issues with GitHub projects because it is the only solution that allows members of the public to submit feature requests and bug reports and then track how those issues are being prioritized within upcoming sprints. Additionally, the use of these tools is free with public repositories and offers other helpful features such as custom fields and views.
NOTE: Given some of the constraints around reporting, we may want to continue to explore options that extend the reporting capabilities of GitHub projects. Similarly, if team productivity is meaningfully affected by the absence of the more robust features that Jira or Zenhub offers, we may want to re-evaluate this decision after an initial trial period.
Positive Consequences
We do not need to purchase licenses or seek ATO approval to start begin tracking tickets and planning sprints
Members of the public can submit feature requests or bug tickets and track how those requests are being prioritized and worked on
We can manage all of our sprint planning and development within the same platform
We can extend GitHub project functionality with custom-built automations
Negative Consequences
We will need to develop custom reports to track some of the same metrics that Jira or Confluence offers out of the box. Our current proposed strategy for doing so is to create a Python script that exports the tickets and produces the following charts at the end of each sprint:
Sprint burndown -- % of tickets and/or points remaining over the course of the sprint
Deliverable burdown -- % of tickets and/or points remaining per deliverable over time
Sprint allocation -- # of tickets and/or points allocated to each team member per sprint
Sprint completion -- # of tickets and/or points created vs planned per sprint
Sprint velocity -- Average # of tickets and/or points completed per sprint
Lead/cycle time -- # of days between creation of a ticket and when that ticket is closed
We will need to spend a bit more time setting up the GitHub project to replicate some of the features that Jira or Confluence offers (e.g. story points, sprints, epics, etc.)
Team members who are familiar with Jira and Zenhub will need to spend a bit more time becoming familiar with GitHub Projects
Comparison Matrix
✅ Feature available, meets requirement
❌ Feature not available, does not meet requirement
🔄 Partial feature, limited feature availability, feature in progress or undergoing improvements
1-3 Strength level
❓Unknown
Pros and Cons of the Options
GitHub Issues + Zenhub
Use GitHub Issues to create and manage development tickets and use Zenhub to organize those tickets into sprints.
Pros
Built off of existing GitHub tickets and functionality
Robust reporting (e.g. burndown charts, velocity, etc.) out of the box
Supports key planning features like story points and epics
Supports issue templates (through GitHub)
Chrome extension to view Zenhub attributes in GitHub
Team has experience working with Zenhub
Cons
Licenses have a monthly fee, even for Government-backed open source projects
Sprint boards can't be viewed without Zenhub login
Moving tickets requires both Zenhub and GitHub logins and write access to the repository
Can be difficult to onboard existing Zenhub users to a new workspace
GitHub form-based templates don't work when creating issues from Zenhub
Limited support for custom views (e.g. no tabular layout)
No support for custom fields
GitHub Issues + GitHub Projects
Use GitHub Issues to create and manage development tickets and use GitHub projects to organize those tickets into sprints.
Pros
Keeps ticket creation and sprint planning in the same platform alongside code
Free for open source repositories
GitHub project boards can be viewed without a GitHub login
Supports issue templates (through GitHub)
Supports multiple views of tickets (e.g. tabular, kanban board, roadmap)
Supports custom fields with multiple data types (e.g. numbers, drop downs, iterations, text fields, etc.)
Supports custom reporting based on those fields
Supports built-in workflow automation and custom automation with GitHub actions
Supports filters on all standard and custom fields
Covered under the existing Grants.gov ATO
Cons
Reporting is less robust than Zenhub and Jira
Requires more initial setup to replicate some of Jira or Zenhub's out-of-the-box features
Team has less experience working with GitHub projects
Jira
Use Confluence's Jira platform for both ticket management and sprint planning.
Pros
Industry standard tool for ticket tracking and sprint planning
Robust reporting (e.g. burndown charts, velocity, etc.) out of the box
Supports custom fields with multiple data types (e.g. numbers, drop downs, text fields, etc.)
Supports multiple views of tickets (e.g. tabular, kanban board, roadmap)
Supports filters on all standard and custom fields
Supports built-in workflow automation
Supports custom ticket templates
Third-party extensions are available to support public access to Jira boards
Team has experience working with Jira
Cons
Licenses have a monthly fee (above 10 users)
Sprint boards can't be viewed without Zenhub login
Members of the public can't submit requests to a Jira board
Requires tracking tickets and planning sprints on a different platform
OpenProject
Use the open source project management tool OpenProject for both ticket management and sprint planning.
Pros
Open source project with self-hosting option
Robust reporting (e.g. burndown charts, velocity, etc.) with enterprise plan
Supports multiple views of tickets (e.g. tabular, kanban board, roadmap)
Supports key planning features like story points and epics out-of-the-box
Cons
Many basic features require enterprise license which has a per-user cost
Higher investment of time to set up and maintain the project
Sprint boards can't be viewed without logging in
Members of the public can't submit requests to a Jira board
Doesn't seem to support issue or ticket templates
Doesn't seem to support workflow automation
Team has less experience working with OpenProject
Links
Last updated