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.
MVC Feature Epics When a Feature Epic and it's associated Design Issue is large enough to break into mulitple MVCs, multiple MVC Feature Epics will be created.
All Feature 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.
Feature Issues are used by our PMs to support tracking on the homepage as well as creating release posts.
Implementation issues allow each Feature Issue to be broken into small, discrete tasks that can move independently through the build workflow steps. Whenever possible, Implementation Issues should also be independently-releasable and provide value to the customer. When they have to be grouped with other Implementatation Issues, a feature branch should be created to merge the dependant pieces of work together prior to merging into the default branch.
Structure of a Singular MVC Feature
Structure of a Multiple MVC Feature
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
Issues that have the
~Deliverable labels require a Release
Post to be ready for publishing along with the
corresponding feature. The schedule to create and review a Release Post is naturally challenging
so, to allow Product Managers to work in parallel, Engineering should add a Documentation stub
early in the WIP
that the final hyperlink to the documentation is available well before the end of the iteration.