There is plenty to improve on the requirements handling from what we did in Jasmine (managing and decomposing). We need to give PMs all the information they need to answer the question -
What is the status of REQ 666? without needing a meeting.
I propose a couple of people working in the background on this to have the tools and infrastructure ready by setting up a small sample project to experiment with gitlab features before we kick off Jasmine+1 to fully be able to exploit its features and develop workarounds for its limitations.
These are some goals I’ve set for myself to simplify how we manage our work. The main goal is to have a fairly transparent project updates structure that scales well to a distributed team (including community contributions) and doesn’t burden the engineering team with too much process.
Please consider them as food for thought to start this discussion:
EPICs for requirements, Iterations for sprints, Labels for Grouping, Milestones for releases
We need to revisit how we used Gitlab features and perhaps consider fitting our workflow into gitlab instead of the other way around.
- EPICs can bring together all the issues being worked on (by different engineers) towards a requirement.
- Iterations will continue to be used as in Jasmine for sprints
- This should allow product and project management to control how broad or how narrow our work should be focused for a given sprint by looking at the EPIC (REQ) and Iteration views and mapping to expertise available. (Currently PMs don’t have a clear view of this w/o talking to REQ assignees)
- As a design pattern to avoid long, complex REQs that span many sprints, we could look into splitting complex REQs into 2-3 EPICs (e.g. MVP, Beta, Production-Ready). Not ALL REQs, just the big, complex ones.
- There could also be templates to decompose a REQ - so we have all the common tasks covered for each REQ e.g. R&D/experimentation, implementation, documentation, marketing/blogpost, infrastructure, etc. so that time is budgeted for these activities more uniformly across REQs.
- Consider using milestones to plan feature-freeze, alpha and beta releases.
Automate data-collection for reporting through tools
We’re a distributed team - engineering meetings should minimize status updates (that can happen offline) and focus on discussing design, solving pressing technical problems.
- Add templates for MRs, Issues, EPICs, etc. and have them automatically checked by CI to flag common errors e.g. missing what REQ an MR is closing, or a signoff
- Engineers should be able to input their weekly updates in gitlab either from web UI or command-line.
- EPIC + issue-level comments should be collected by tools every week and then massaged into REQ-level updates by PM. See similar tools
- Generate sprint-loading graphs, and REQ-related spread dynamically
- Auto-label issues added to an EPIC
Use a single tool
The OpenProject requirement system is supposed to be a high-level view of the feature roadmap to discuss with partners and show a few fields that gitlab doesn’t handle currently (REQ owner, priority, %complete, backlog vs. scheduled). With EPICs now gaining the ability to aggregate weights in the last release of gitlab, the %complete is doable on gitlab now. Labels can be used to track the status of the REQ.
- I propose not to migrate OpenProject for the NewCo migration. OpenProject + Gitlab hasn’t been a seamless experience.
- Since gitlab is integral to the engineering team, I propose to move everything to gitlab and retire OpenProject.
- Dilute some of our requirements for tools to manage Product Requirements and be prepared to work around gitlab limitations using API tooling and reports.
Gitlab has limitations - can we work around them using API tools or perhaps by diluting our requirements in some cases?
- EPICs (mapped to REQ in this proposal) cannot be assigned to a single person - consider dilution of this requirement.
- EPICs can not have priorities - how do we deal with low priority REQs that we know we won’t have time for? Labels?
- Weights for shared dependencies aren’t tracked correctly (and counted multiple times) - set up best practices to not have issue hierarchies
- Projects may not have EPICs (e.g. OSTC/Requirements) but SubGroups may have EPICs (e.g. OSTC/OHOS)
- Can EPICs in one subgroup (e.g. OSTC/Requirements) collect issues from other subgroups?
- What properties are we missing here and who does it affect most?
- What additional tools do we need to create to assist with this plan?
- Do we need to hire someone to assist with the tools?
- Who will own the tools and document the policies?
- Where should impromptu work (not directly related to REQ) be accounted? Do we need a catch-all EPIC for each core area?
- Would using Gitlab as described here alleviate our reporting issues?
- How would we use Gitlab Requirements? These are separate from our REQs which are more like project features.