This flow is a visual representation of the Product Development Flow handbook page. It does not include many of the detailed steps and interactions occurring within phases nor the transitions of various workflows labels. It's also worth noting that, while Product Management, UX and Engineering have ownership of some phases, all teams work collaboratively throughout the entire process.
Box colours represent the type of issue:
Box shapes represents whose responsibility it is to get it done:
And issue labels look like this:
We use Epics to contain all issues related to a Solution so that when an Epic is closed, it indicates the Solution is live and available. Key points about Epics:
The Feature Epic proceeds to
~"workflow::planning breakdown" along with the Design Issue. Here,
the Design Issue goes through a final review with Product Management and Engineering before one or
more Implementation Issues are created.
Before moving to the next phase, the Design Issue is closed and the resulting final designs and requirements are copied to the Feature Epic, which becomes a clear, without distractions, SSOT for the solution. The closed Design Issue serves as a historical record of how we reached decisions.
The Feature Epic serves as an organizational entity as well as single source of overall requirements from the original problem issue.
The Epic should have enough information to convey the overall intended value realized after all child Implementation Issues are delivered. Final requirements and design assets, if available, are copied here from the Design Issue for reference; at this point the Design Issue is closed. The Epic is closed when all Issues are delivered.
All Implementation Issues rolling-up to the Feature Epic are their own MVCs in that they are independently-releasable slices of value. Each issue contains its own criteria for delivery, including any implementation details and links to relevant design assets for just this Issue.
The Engineering Manager is responsible for ensuring these are created, refined and contain
~"workflow::scheduling" label is then applied to indicate to the Product Manager
that an Issue is ready for scheduling by being assigned a Milestone.
Once an Implementation Issue has a weigth and a Milestone, it receives the