Review Defend's usage of Epics in the Development Workflow and integrate within Secure Workflow
Problem to solve
Some issues assigned to a given milestone are misleading information for our users as they don't always represent a feature that will actually be shipped within the corresponding milestone. E.g. an issue in workflowdesign is set to %12.9 as we expect Product Designer and Engineers to work on it during this iteration but we do not expect to deliver the feature within %12.9, the implementation is likely to happen in %12.10 or even later.
Proposal
Consider switching the existing Secure workflow to be closer to the new process that Defend is using. At a high level, requirements are being moved to an epic and each step of the workflow is its own issue (e.g., Design, Front-end, Tech Docs...). This allows us to set the target release on the epic (via due date) and assign the issue to the milestone in which it will be worked on. This provides better visibility to our customers on when a new feature will be released as they do not need to read and grok our development workflow.
Conclusion
After reviewing and discussing here is what I think (@gonzoyumo) make sense and we agree on (or nobody objected to):
- Always create an epic when working on a feature, and put the validation issue (aka design issue) in it. This makes sure we always follow the same workflow instead of only creating epic during planning breakdown when the feature needs multiple iterations to be completed.
- Always close the validation issue (after planning breakdown) and open at least one implementation issue, and add them to the feature epic.
- When completing design/discovery, put the content of the conclusion in the epic. Even if this duplicates what's already in the design issue it clarifies the expectation of the feature at the epic level.
And here is a list of things that I think should not be adopted or are still debatable and might be postponed or need a quick decision to be integrated into the Secure workflow:
- Setting the due date on the feature epic. Unless there is a strict need, priority may change and if we have multiple iterations to go through to achieve a feature, it's hard to predict the due date. We instead favor relying on the automatic due date based on child-issues.
- Applying workflow label to the feature epic. It's hard to keep this in sync when there are multiple iterations. The child-issues list (open/closed state of issues, their milestone, their health status) should provide enough data about the overall state of the epic.
- Replacing sub-issue convention with
MVC epic
andfeature issue
. See this thread