> For the complete documentation index, see [llms.txt](https://atd-dts.gitbook.io/wiki/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://atd-dts.gitbook.io/wiki/product-ops/github-project-management.md). # Managing Services & Projects with GitHub The Data and Technology Services teamuses GitHub Projects for agile project management. This is an overview of our process. {% hint style="warning" %} ## This page is in the process of being updated to reflect our migration from Zenhub to GitHub Projects. {% endhint %} ## Set up 1. [Create a GitHub account](https://github.com/join) if you don't have one already. 2. Have someone on the DTS team add you to the [City of Austin](https://github.com/cityofaustin) organization and the [Transportation](https://github.com/orgs/cityofaustin/teams/transportation) team as a Maintainer. ## Status Status is the way we track issues across various stages of completion. We use the following statuses: * **New** - Awaiting triage by the Service Desk, Team Lead, or Product Manager * **Needs Scoping** - Potential projects or features that require clarification or exploration before presenting to builders for estimation and prioritizing * **Backlog** - Ready to be tackled by the team when the time comes * **On Deck** - Slated for work in the current sprint * **In Progress** - Actively underway * **Review/QA** - Proposed as complete - pending teammate or stakeholder sign-off * **Blocked** - Issues that cannot be completed — often waiting on ATS or user feedback * **Closed** - Completed, closed as not planned, or closed as a duplicate * **Ongoing** - A continual service, product, or task - no projects, no epics * **Icebox** - Not under consideration at this time {% hint style="info" %} Closing an issue, by default, records it as something we completed. If it's closed for a different reason, you can click the caret on the "Close" button to note this:


If the work wasn't executed, make sure to delete the estimate from the issue so that we can keep our service delivery metrics accurate. {% endhint %} ## Issues Tracking our work in issues not only helps us stay organized, it gives us important data on where we're spending our time, how to prioritize work, . or bookmark a link to [this DTS issue form](https://github.com/cityofaustin/atd-data-tech/issues/new?template=--%20dts-issue.yml). ![Screenshot of the Issues page with the "New issue" button circled. ](https://github.com/cityofaustin/atd-data-tech/raw/master/images/Create-new-issue.png?raw=true) You will see a list of our custom issue templates. These are handy for creating bug reports, meetings, etc. with boilerplate information and structure. If you prefer to start with a blank issue, scroll to the bottom of the template list and select "Blank issue." ### Issue Titles Issue titles should **begin with a verb**\* and **summarize the work to be completed**. This convention improves data readability and helps keep our tasks action-oriented and unambiguous. Since you'll be using `Product:` and `Type:` labels, you don't need to spell out application names or issue types. \*Consider *Update, Implement, Add, Remove, Review, Discuss, Troubleshoot...* | Use this | Not this | | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | Add task order fields to "Funding" tab | AMD staff can't track all funding information | | Publish new CCTV camera thumbnails | CCTV map issues | |

Replace Vision Zero Editor council district dataset

— or —
Replace VZE council district dataset

| Outdated council district AGOL resource in Vision Zero Editor | ### Issue Types {% hint style="info" %} We are not currently using issue types and fields in a standardized way outside Product, Project, and Service indexes. {% endhint %} | Type name | Description | Fields | | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | [Task](https://github.com/organizations/cityofaustin/settings/issue-types/390755) | A specific piece of work | DTS Team, DTS Status, TPW Division, DTS Estimate | | [Epic](https://github.com/organizations/cityofaustin/settings/issue-types/31590611) | Large (but sub-Project or Service) body of work—like a feature, roll out, or grouped tasks within a service | TPW Division, DTS Status, Start date, End date, DTS Estimate, DTS Teams | | [Service](https://github.com/organizations/cityofaustin/settings/issue-types/31105742) | Ongoing consultation, training, or assistance to support the use of data and technology | DTS Status, DTS Team, TPW Division, DTS Description | | [Product](https://github.com/organizations/cityofaustin/settings/issue-types/31431867) | Applications and digital systems we build in-house | DTS Status, DTS Team, TPW Division, DTS Description, DTS Solution Type, DTS Application URL | | [Project](https://github.com/organizations/cityofaustin/settings/issue-types/26551850) | Substantial endeavor requiring coordinated effort across multiple sprints and/or teams | DTS Status, TPW Division, Start date, End date, DTS Description, DTS Teams | ## Labels You can apply labels by clicking the "Labels" heading in an issue's right-hand sidebar and beginning to type the label name.
Screenshot of Github label UI predictive typing: "SM" is typed and "Workgroup: SMD" is suggested in the drop down with the description "Signs and Markings Division"

Label descriptions help with acronyms, "Type:" definitions, etc.

### The importance of labels Accurate labeling is necessary for several reasons: * Labels allow us to view related issues across the Zenhub pipelines. For example, during Apps Team Sprint Planning, we filter down to `Team: Apps` and during our periodic meetings with AMD we use the `Workgroup: AMD` label to look at all the work — across teams, of all sizes — that we're doing for them. * Labels are also used to populate [content on the DTS website](https://austinmobility.io/projects). * Finally, labels are critical to the [service delivery data](https://data.austintexas.gov/Transportation-and-Mobility/Transportation-Public-Works-Data-Tech-Services-Iss/rzwg-fyv8/about_data) that we use to track, analyze, and improve our work. ### Required labels * [**Workgroup**](https://github.com/cityofaustin/atd-data-tech/labels?q=Workgroup%3A+) - the customer we're serving; `Workgroup: DTS` for internal work and `Workgroup: TPW` for department-wide work. **Every issue should have one, and only one,** `Workgroup:` l**abel**. * [**Team**](https://github.com/cityofaustin/atd-data-tech/labels?q=Team%3A) - the DTS service team who will be doing the work. If there are two teams working on the same thing, copy the issue so there's one for each team. * Products, Services, and **Tasks should have one, and only one,** `Team:` **label**. * Projects and Epics may be assigned to multiple teams. * At least one **Project**, **Product,** or **Service** label. * [**Projects**](https://github.com/cityofaustin/atd-data-tech/labels?q=Project%3A) are time-boxed endeavors — whether [identifying a vendor solution](https://github.com/cityofaustin/atd-data-tech/issues/65), [building a major feature for an existing Product](https://github.com/cityofaustin/atd-data-tech/issues/533), [overhauling a dataset](https://github.com/cityofaustin/atd-data-tech/issues/254), or [delivering a complex map](https://github.com/cityofaustin/atd-data-tech/issues/1911). They accomplish a singular goal and have a defined completion date. * [**Products**](https://austinmobility.io/services) are solutions that we continue to support over time, including all in-house applications, such as the [Finance and Purchasing Portal](https://austinmobility.io/products/2903) and the [Vision Zero Crash Data System](https://austinmobility.io/products/255). * [**Services**](https://austinmobility.io/services) are ongoing consultations, training, or assistance to support the use of data and technology. Each DTS team offers multiple services, such as [Geodata Quality Control](https://austinmobility.io/services/28553) and [Software License Administration & Installation](https://austinmobility.io/services/27294). Often, a major feature or enhancement to an existing product will require enough resources and coordination that it qualifies as a project. [Warehouse Inventory](https://github.com/cityofaustin/atd-data-tech/issues/20), for example, was a major set of features and enhancements to [AMD Data Tracker](https://austinmobility.io/products/2068), so it needed both **Product** and **Project** labels. ### Optional labels A DTS team or individual product manager may find these additional label categories helpful * ​[**Type**](https://github.com/cityofaustin/atd-data-tech/labels?q=Type%3A) - The type of request or task * [**Workgroup**](https://github.com/cityofaustin/atd-data-tech/labels?q=Workgroup) - Specific teams within TPW divisions, e.g. Street & Bridge Operations has 5 workgroups—District Maintenance, Logistics, Pavement Operations, Infrastructure Operations, Utilities and Structures * [**Impact**](https://github.com/cityofaustin/atd-data-tech/labels?q=Impact%3A+) - The effect of a bug, infrastructure failure, etc. * `Impact: 1-Severe` — Severely impacts TPW service delivery * `Impact: 2-Major` — Causes a major interruption of TPW service delivery * `Impact: 3-Minor` — Deteriorates TPW service delivery * `Impact: 4-None` — Does not affect TPW service delivery * [**Need**](https://github.com/cityofaustin/atd-data-tech/labels?q=Need%3A) - To designate priority of a potential feature or enhancement * `Impact: 1-Severe` — Severely impacts TPW service delivery * `Impact: 2-Major` — Causes a major interruption of TPW service delivery * `Impact: 3-Minor` — Deteriorates TPW service delivery * `Impact: 4-None` — Does not affect TPW service delivery * [**Provider**](https://github.com/cityofaustin/atd-data-tech/labels?q=Provider%3A) - The external team or vendor executing the issue ## Estimates Estimates are how we track the level of effort of issues. Tasks should always have an estimate once pulled on deck or into progress, and estimates can be adjusted as needed. Check estimates for accuracy whenever you close an issue. Leave estimates blank for duplicates and other issues we decide not to undertake. Like labels, **estimates are required** because they are a critical component of the [service delivery data](https://data.austintexas.gov/Transportation-and-Mobility/Transportation-Public-Works-Data-Tech-Services-Iss/rzwg-fyv8/about_data) we use to track, analyze, and improve our work. Estimates are also useful for * Sprint planning — to see when a person or team has too many issues (or too few!) issues assigned to themS * Stakeholder discussions when prioritizing features — being able to show stakeholders easily that we can accomplish, say, three small tasks, two medium, or one large * [Velocity tracking](https://www.zenhub.com/blog/track-your-speed-of-work-with-agile-velocity-charts/) — i.e. predicting the likelihood we can complete a project by a given date
*Curious why we use* [*Fibonacci*](https://en.wikipedia.org/wiki/Fibonacci_sequence) *numbers for our estimates? Check out this* [*lengthy explanation*](https://www.agilebin.com/blog/10-reasons-to-use-fibonacci-sequence-for-story-points)*.* ## Assignees An issue should be assigned to the person/people who will tackle it. This enables team members to filter down to issues they are responsible for easily.