Productsare the solutions we build for our customers, including Knack apps, AMANDA apps, custom software, and data systems. We improve and extend our products over time so that they deliver continuous value to Austin Transportation as business needs evolve.
Projects are time-boxed endeavors. They accomplish a singular goal and have a defined completion date. Examples include:
Delivering the first iteration (MVP) of a new DTS product
Project Initiation
Oftentimes, our customers initiate a project by submitting a DTS service request that is notably large and/or important.
A DTS team member may also create a project when there is significant work to be done on an internal product—such as , , or .
In either case, we begin by verifying that all our DTS project prerequisites are met:
Dedicated product owner to support requirements gathering, user research, and user onboarding
Division Manager sponsor to champion the project at the executive level
A commitment from the customer to collaborate in DTS's iterative, user-centered development process
Then either or convert the existing issue to match the . Either way, make sure that the 'Project Index' label is on the issue so that an evaluation record for the project is added to the DTS Portal and it appears on the website.
Don't worry about building out a robust project index before scoping the request. Just make sure the name and description (the first 1-2 sentences) are good and that it has all the right labels. You can comment out the rest of the template to fill out when you have more information.
Move the issue to the "Needs Scoping" Zenhub pipeline.
Scoping
PM schedules an intake meeting. Ideally, this will include actual users as well as the workgroup manager.
Prepare .
Meet and take notes; photos/recording may also be helpful.
Builder Huddle
PM sets up meeting with potential builders, e.g. Dev for a Vision Zero Viewer project, Apps for a ROW Portal project. If we aren't sure which route we'll go or the solution will require both, add to the to discuss.
Prepare a summary of request. Here's an ().
At the meeting, discuss the recommended approach and fill out the "Effort" section of the .
Sometimes we realize that the request isn't actually project-sized during the intake meeting or the builder huddle. No worries, we had a good opportunity to learn more about our customers' work. Might make sense to organize this work as an , once the time comes.
Product Sync
After assessing effort with the builders, it's time to assess value with the product team.
Add to for a "Refinement-week", i.e. the second Wednesday in a sprint. If feedback is needed sooner, or the project was initiated internally (like work on our technical infrastructure), bring it to instead.
As a group, fill out the "Value" section of the .
After the evaluation is complete, the Austinmobility.io script will pick them up and you will be able to see the project in relation to other projects in our backlog using the .
Move the index issue into the "Backlog" pipeline.
Prioritization
Google presentation used for Product Ops onboarding and TPW Executive communications.
Working docs
Activation
Once the time comes to work on the project:
Move the issue to the "In Progress" pipeline.
If you don't already have regular Sprint Reviews with the project's stakeholders, set up recurring meetings for the duration of the project so that you can demo work and get feedback.
Create a folder in the Projects/Products DTS Drive.
Convert the project index issue into an epic and assign future issues to the epic moving forward. Zenhub allows you to nest epics or assign issues to multiple epics, so feel free to use that functionality if you find it helpful.
Ensure that everyone who has stake in the project, from potentially impacted staff to interested executives, is aware the project is moving forward. Invite stakeholders to come to sprint reviews and/or participate in user research. Ask them who else should be included.
Optionally, hold a with your stakeholders.
Delivery
Perform requirements gathering with users. We often begin with and store requirements either as for in-house applications or in a software comparison matrix for off-the-shelf solutions.
Document bugs, feature requests, and enhancements as Github issues. You may want to encourage your users to contribute using the .
When you click the "New Issue" button in the upper righthand corner of most pages in Github, you'll find issue templates for bug reports, features, and enhancements. You have to scroll to the bottom of the page and click to the "Open a blank issue" link to get a plain issue. To skip all that, bookmark the and add it to your browser bar.
Work with the team lead—via Github comments or in a planning/refinement/sync meeting—to assign an to each issue. Zenhub's is also a fun way to estimate asynchronously.
Bring complex issues to Backlog Refinement ( | ) to discuss with builders. Break them up into smaller issues as necessary, document the agreed-upon approach, and align on an .
Prioritize work with stakeholders during Sprint Reviews.
Completion
A project is considered complete when the minimum viable product—captured in the "Scope and Deliverables" section of the issue's project index—is delivered to users.
For complex projects, you might consider making an "Onboarding and Stabilization" epic in the project to capture any critical bugs documentation needs that surface during roll out and keeping the project open until those issues are addressed.
Often, there are still issues in the backlog that are not actually must-haves. Remove the project label, remove them from the epic, and review them the next time you meet with stakeholders so they can prioritize those against any of their other ongoing requests.
Retire the project label by adding "[Archive]" to the "Description" field and update the hex code to #B8B8B7.
Write a final update as a comment on the index issue and close the issue.
By default, completed projects show on of the website, but you can apply the Archived Project label to prevent that. We like to curate this page to showcase our most compelling, impactful, and well-documented work.
Add notes/photos/recording to Github issue.
If necessary, update issue description to ensure it clearly summarizes request.
. Fill out the "Description" field and use the hex code #3D3D3D for "Color." Use this label for all issues moving forward so that they render on the projects' website page and are easy to surface on Zenhub/Github.
Fill out the rest of the project index including background, outcomes, timeline, etc. Add these headings to the issue:
If practical, versions of an application on a regular basis.
Perform usability testing to surface improvements to the user experience. Since we don't have dedicated user researchers at DTS, we love for its simplicity and depth of insight. we've done. It's handy to record sessions on Teams so that you can expand on your notes, embed screenshots/clips in issues, etc.
## Scope & Deliverables
What are we delivering? What’s in scope, and what isn’t? Describe constraints you’re working with, e.g. “Can’t impact **\_**‘s workflow,” known roadblocks.
## Desired Outcomes
Impact this project can have, success metrics
## Timebox
How long should this take to build; optional section w/ caveats for more complex projects.
## References
- Google Drive link
