Explore how a request becomes an initiative, a delivery issue, and a sprint plan. Separate what we’ve observed from what we’re proposing.
Proposed process · from intake to sprint selection
Follow one request through the handoffs.
Choose a route, then follow the connected steps. Each step shows who prepares the work, what the review decides, and what moves forward.
Group structure and board visibility
Current model: SEC, Dispatcher Phoenix, and Dispatcher Stratus are separate group roots. SEC / Epic / Intake holds incoming issues centrally; delivery issues move to their owning product projects. SEC epics can coordinate those issues, but a SEC group issue board does not combine product-project issues across these roots.
A common ancestor is a separate option: shared issue views could span the product projects, letting known-owner requests stay in their owning project. This exploration uses the current separate-group structure. Board names and issue preparation stages below are proposed views that still require team agreement.
01 · Understand the levels
Keep the goal connected to the work.
Initiatives define the outcome. Capability epics define the capabilities. Issues define the specific changes teams deliver.
Proposed model · illustrative Fleet Analytics examples
01 · Initiative
The outcome
What result are we pursuing, and why?
A coordinated effort to achieve a customer or business outcome. It defines the shared goal, scope, accountable owner, and success measures.
Illustrative example
Initiative — Fleet Analytics and Reporting
Help administrators make better-informed fleet decisions. The specific outcome and measures still need agreement.
Owns the overall outcome and tradeoffs across capabilities. Review success measures alongside delivery progress.
A substantial, bounded capability that contributes to the initiative. It defines functionality and clear completion criteria.
Illustrative example
Historical Analytics
Enable administrators to examine device usage over time. Other proposed capabilities include Standard Fleet Reports, Device Lifecycle Management, and Custom Report Builder.
Owns capability scope and delivery. Track child issues, dependencies, and completion criteria; delivery may span several sprints.
GitLab: Epic · level::capability · linked to the initiative
↓ Delivered through
03 · Delivery issue
The specific change
What will the team build and test?
A testable change with expected behavior, acceptance criteria, and a scope the team can estimate and deliver.
Illustrative example
Display usage changes over a selected period
One delivery issue contributing to Historical Analytics. Recording periodic device readings could be another.
Owns implementation and validation. Track readiness, effort, ownership, development, and testing; assign an iteration when selected for a sprint.
GitLab: Issue · child item of the capability epic
“Initiative” describes a planning purpose in this proposal; it is represented by an Epic work item. Capability epics also use the Epic type. Issue is the delivery item type; “child item” describes its relationship to the epic. Standalone issues do not require an epic or initiative.
02 · Why the distinction matters
Breaking down the work preserves the goal.
Direction
Every capability and delivery issue connects to a customer or business objective.
Accountability
The overall outcome retains an owner after breakdown, across teams and releases.
Visibility
Product can review outcomes, capability delivery, and sprint work separately.
Completed issues contribute to a capability. Delivered capabilities contribute to an outcome. Neither automatically proves the next level is complete. Ownership, success measures, and regular reviews make the structure useful.
03 · Compare the change
Current practice and the proposed model
Observed practices and open questions, compared at the same planning levels.
01
Initiative
Current · observed
Original epic retained during breakdown
Fleet Analytics and Reporting is retained during breakdown and already has Linked items relationships to the resulting capability epics. Related titles also use a shared name prefix.
Working assumption After breakdown, the overall initiative and its outcome are not tracked at a higher level; tracking continues through the resulting capability epics.
Proposed
Retain a clearly identified initiative
Use the title Initiative — Fleet Analytics and Reporting and level::initiative. Move it from intake into a dedicated initiative view, retaining an owner, overall status, success measures, capability summary, and review cadence.
02
Capability
Current · observed
Capability epics already linked
The resulting epics represent pieces of the larger initiative and are already connected through Linked items. A shared title prefix also signals their association; the links establish a relationship rather than native containment.
Proposed
Keep the links; clarify each epic’s purpose
Keep the existing Linked items relationships and apply level::capability to delivery capabilities. Each has its own scope and completion criteria. The initiative owner maintains their combined status and contribution to the overall outcome.
03
Sprint delivery
Current · observed
Epic structure reflects sprint scope
Teams choose child issues from epics labeled for the sprint. To represent the actual commitment, an epic may be divided into sprint-sized work containers, or given additional sprint labels as its issues are scheduled across sprints.
Effect The capability breakdown and sprint plan become intertwined: epic structure or labels must change to reflect when its issues will be delivered.
Proposed
Separate capability scope from sprint allocation
Keep capability epics organized around the functionality being delivered. Select specific issues across epics and standalone work, check their combined effort against team capacity, and assign sprint iterations to those issues.
Benefit A capability’s issues can span several sprints without dividing its epic into sprint containers. Track selected issues by team and sprint; keep the epic focused on capability progress and forecast.
Guiding recommendation
Leaving intake should change the initiative’s planning view, not end its accountability.
04 · How we manage it in GitLab
Put section 03 into practice: keep the capability structure stable, record sprint allocation on delivery issues, and review the overall outcome at initiative level. This is a proposed configuration, not the installed workflow.
1. Create and connect the working records
Record / location
Configure in GitLab
Maintain on the record
Initiative Epic in SEC
Retain and rename the original epic Initiative — Fleet Analytics and Reporting. Apply level::initiative. Maintain a capability summary table in its description.
Retain existing capability epics and their Linked items relationships; create additional capabilities only where agreed scope requires them. Apply level::capability.
Delivery issue Owning Phoenix or Stratus component project
Create or retain the issue in its project. Add it as a child item of the capability epic. Standalone issues remain without an epic parent.
Acceptance criteria, readiness, estimate / weight, assignee, proposed team label, and iteration when selected.
Use the confirmed Linked items → relates to relationship. Add it once; it appears on both epics. It does not identify which epic is the initiative, so the naming convention and level labels establish that meaning. Maintain initiative summaries manually; capability-to-issue relationships remain native child items.
Maintain the agreed record in the description: use a table with capability link, owner, status, target, and dependencies. Add a last-reviewed date. Comments support discussion; incorporate agreed decisions into the description. The initiative owner updates the summary at the agreed review cadence; linked epics do not update these fields automatically.
Naming and tracking policy
Initiative title:Initiative — [Name], with level::initiative. Capability label:level::capability. Use descriptive capability titles; a name prefix is optional for readability.
Initiative and capability are planning roles of the Epic work-item type. Keep initiative epics active after intake and breakdown, in a dedicated initiative board or filtered view. Assign an accountable owner and review cadence; complete or cancel the initiative after evaluating its outcome. Removing it from intake must not remove it from ongoing tracking.
2. Set up views for different decisions
SEC initiative view
Filter epics by level::initiative. When intake ends, keep the initiative active here with an accountable owner. Product reviews overall status, outcomes, risks, decisions, dependencies, and the next review date.
SEC capability view
Filter by level::capability. Review sequencing, targets, dependencies, child-issue progress, and forecasts across sprints.
Product issue views
Within each product group, use a preparation / ordered backlog view and a sprint issue board. Include epic children and standalone issues together.
Agree the issue-readiness labels and their owners before configuring the backlog. For sprint views, use an agreed team label (for example team::A) and the selected iteration. These are views of the same issues, not copies or additional epic containers.
Current group constraint: SEC, Phoenix, and Stratus are separate roots. A SEC group issue board does not combine their product projects. Use product-group issue views and link them from SEC for now; a common ancestor is a separate structural option. Team labels and iteration dates need coordination across the separate groups.
3. Select and record sprint scope on issues
Product and the delivery team review ready issues across capabilities and standalone work, considering priority and dependencies.
Check the selected issues’ combined estimates against available development and testing capacity. An iteration records the timebox; it does not decide capacity.
Set the agreed team label, assignee, and sprint iteration on each selected issue. Use iterations available to that issue’s product group; leave unselected issues in the backlog.
Filter the team’s issue board to that iteration. Track individual issue development, testing, and completion using the agreed workflow.
Example: Historical Analytics has ten issues. Assign three to Sprint 17 and others to later iterations when selected. Keep one Historical Analytics capability epic; do not divide it solely to match sprint boundaries.
4. Keep delivery and outcome reviews connected
During the sprint: update the selected issues and record blockers or scope changes. If work moves to another sprint, update its iteration and reassess the plan rather than reshaping its capability epic.
At capability review: inspect child-issue progress, dependencies, and remaining work; update target dates and the forecast. If SEC retains epic sprint labels, treat them as a maintained forecast summary, not the record of exact sprint scope. Do not assume they synchronize automatically with child iterations.
At initiative review: the initiative owner consolidates capability status and evaluates success measures. Maintain the capability table and an overall narrative status manually. Keep the initiative active until its outcome is delivered, reduced, or cancelled; completed issues alone do not establish success.
5. Native nesting: optional improvement
Check the installed version, license, and permissions. Ordinary epics require Premium or Ultimate; nested epics require Ultimate. Verify adding existing product-project issues beneath SEC capability epics; cross-group links do not expand board scope.
If native nesting is confirmed available later, connect capability epics as children of the initiative epic and use supported progress summaries. Retain outcome reviews and the accountable owner. Until then, explicit links and the manually maintained summary are the implementation plan; issue-level sprint allocation works independently of epic nesting.
Use these questions to test the model with one epic child and one standalone request. Checking a box records your review locally; it does not indicate organizational approval.
Saved only in this browser. Use export to bring notes back into our next iteration.
Research opportunity · SEC availability unverified
GitLab Duo — AI-assisted planning
Help prepare and analyze the work. Keep people accountable for the decisions.
What is GitLab Duo?
GitLab’s integrated AI platform supports planning, development, testing, and delivery through conversational assistance and specialized agents working with available GitLab context.
Why explore the Planner Agent? It is the planning-focused agent most relevant to this proposal: potential assistance with work definition, breakdown, backlog analysis, and status reporting.
This explorer demonstrates possible uses. It does not connect to GitLab Duo or run these prompts.
The process still comes first
Duo assists the process; it does not define it.
SEC still needs agreed initiative tracking, ownership, relationships, requirements documentation, prioritization, and readiness rules. Drafts and AI-generated estimates require human review before becoming agreed delivery requirements.
01 · Where assistance could fit
The same ADOM steps, with help preparing them.
Proposed SEC applications, not confirmed functionality on the SEC instance.
ADOM activity
Potential Duo assistance
Human decision / review
Product intake
Summarize requests; flag missing information and possible duplicates.
Confirm the problem, evidence, duplicates, and route.
Epic definition
Draft objectives, requirements, scope, and acceptance criteria.
Agree scope, owner, outcome measures, and exclusions.
Epic breakdown
Propose capability areas, user stories, and delivery issues.
Validate useful slices, feasibility, boundaries, and testability.
Technical review
Surface documented dependencies, blocked work, and possible gaps.
Engineering / QA validate dependencies, security, and technical conclusions.
Backlog refinement
Find stale items, unclear requirements, and incomplete records.
Decide what to clarify, reprioritize, defer, or close.
Sprint planning
Summarize candidates, suggest relative effort, and surface risks.
The team validates estimates, dependencies, capacity, and exact issue selection.
Progress reporting
Summarize completion, remaining work, and blockers.
Verify source records and separately assess initiative outcomes.
02 · Try the idea with Fleet Analytics
Prompt examples for an initiative and its capabilities
Supply the initiative and relevant capability / issue URLs. Fleet Analytics uses related epics, so explicitly name that structure rather than assuming the agent will traverse a native child-epic hierarchy.
Examples are draft evaluation prompts. Results depend on accessible context, installed capabilities, and permissions. Any claims of missing work or dependencies need verification.
03 · Availability and practical limits
GitLab documents Planner Agent support for self-managed installations. SEC access is unverified. Its documented history begins with beta in 18.6, create/edit support in 18.7, and general availability in 18.8; newer actions vary by version. These facts do not establish what SEC has enabled.
Administration: confirm installed version, Duo entitlement / credits, cost, and foundational-agent configuration.
Actions: confirm whether analysis, creation, editing, and linking are supported and permitted. Duo access does not establish availability of native nested epics.
Context: test coverage across SEC, Phoenix, and Stratus; give explicit URLs and check whether all related items were read.
Governance: confirm security, data access, AI-use approval, and administrative requirements before using internal records.
Documented limitations: large item collections can reduce response quality; long comment histories may be incomplete; verify reported edits on the records themselves. Keeping agreed requirements current in descriptions improves the evaluation’s source material.
04 · Suggested limited evaluation
Start with preparation and summaries.
Confirm access and governance with the appropriate SEC administrators.
Use one existing capability epic and a small set of its issues. Request a requirements review and draft breakdown without editing records.
Compare the result with Product, Engineering, and QA review. Measure preparation time, correction effort, coverage, and usefulness.
Test an initiative summary using explicit links. Check whether completed work, blockers, and remaining scope match the source records.
Recommendation: evaluate whether Duo reduces manual preparation and improves issue clarity and summaries. Expand only after the team judges the results useful and agrees any permitted write actions.
Status: research opportunity — not an approved SEC capability or implementation plan.