Skip to content

Planning flow

This is the recommended path for a planner who turns validated specification scope into reviewable planning baselines. Use it when you need a rough effort range in the Plan's selected unit, confidence, readiness signals, factor evidence, and an auditable decision before downstream implementation work starts.

Planning is not delivery scheduling and it is not a commitment. It produces planning guidance from specification artifacts, AI-extracted factors, and the estimation profile selected on the Plan. Humans still decide whether the assessment is credible enough to accept, override, or supersede.

Before you start, make sure Planning is enabled, your role can open Plans, and the target specification already has meaningful Epics, Requirements, and preferably Use Cases. Test Cases are optional, but they improve the test factor. A first walkthrough usually takes 10 to 20 minutes per Planning Scope, depending on how much review the generated assessment needs.

Flow overview

  1. Confirm that the specification is ready for planning.
  2. Create or open a spec-scoped Plan.
  3. Review Scope Coverage for each Planning Scope.
  4. Generate a Scope Assessment.
  5. Review the Scope Items breakdown and assessment drivers.
  6. Accept, override, or supersede the assessment.
  7. Generate and review Role Allocation and Specification Allocation.
  8. Generate and review the Plan-level Minimum Baseline.
  9. Project the accepted Minimum Baseline into Feature Candidates.
  10. Review Remaining Scope and create Extensions for later coverage.
  11. Maintain the planning baseline as the specification changes.

Page guides used in this flow

1. Confirm that the specification is ready for planning

Pages used: Project page, Specifications page, and Analyst flow

Planning depends on the quality and relationships of the specification artifacts. Before creating or accepting planning estimates, check that the target Epic has enough refined content.

Recommended input quality:

  • Requirements should be clear enough to classify into UI, backend, data, integration, security, and test factors.
  • Use Cases should exist when possible. Planning uses Use Cases as the primary scope items because they usually describe coherent behavior.
  • Requirements that are not linked to any Use Case are still included as fallback rows so they do not disappear from planning.
  • Test Cases, when present, are used for test-factor classification. If no Test Cases are linked, Planning derives the test factor from Use Cases or fallback Requirements.

What to expect:

  • incomplete links do not always block assessment generation
  • weak links produce weaker evidence and lower confidence
  • missing Test Cases are visible as coverage gaps, not as automatic failures

If the scope is still raw, use the Analyst flow first. The Planning flow is most useful after Requirements and Use Cases are understandable enough for human review.

2. Create or open a spec-scoped Plan

Pages used: Plans page and Plan detail page

Open Plans from the top-level navigation or from the project page. A Plan is scoped to one Specification and contains one Planning Scope for each selected Epic.

On bilingual Projects, New Plan, Add Scope, inherited Scope names and descriptions, Scope Items, allocations, and Feature Candidate source previews use the primary Project language, independently of the interface language. Artifact keys stay unchanged. Custom Scope names and descriptions remain as entered. Missing translations are marked Translation required. Use Case titles store canonical English and the Project-language title together; edit the Use Case or use Generate title to synchronize an older title. These actions run through the Specification background synchronization job. Planning does not translate or rewrite existing source artifacts when you open a page. Epics created through Project Bootstrap or promoted from Project Workspace keep their bilingual titles. Use Cases subsequently created in those Epics use the same title synchronization as other Specification Use Cases. New Specialist review history entries retain the title translations captured with the event. Renaming a source later does not relabel those historical entries. Existing history retains its originally recorded labels.

Use a new Plan when:

  • the specification has not been planned yet
  • you need a separate planning container for a new planning cycle
  • the previous Plan is intentionally being superseded instead of updated

Use an existing Plan when:

  • you are continuing review for the same Specification and scope set
  • you need to inspect accepted baselines, assessment history, or timeline activity
  • you need to add a missing Epic as another Scope

What to expect:

  • Plans can be edited in any lifecycle state; editing an accepted or superseded Plan reopens it as draft
  • legacy epic-scoped Plans are view-only in the new spec-scoped Plan detail page
  • a parent Plan is not fully accepted until every active Scope has an accepted baseline

3. Review Scope Coverage

Pages used: Planning Scope page

Open a Planning Scope from the Plan detail page and start in Overview. Review the context tree first so you know which Project, Plan, Scope, and source Epic you are assessing.

In Scope Coverage, check:

  • source Epic
  • Scope description
  • accepted baseline summary, if one already exists
  • planning item count
  • Requirement and Use Case coverage
  • fallback Requirements not linked to Use Cases
  • Test Case evidence

Use Refresh Coverage when links or source artifacts changed and the coverage summary needs to be recalculated.

Decision guidance:

  • If the wrong Epic or Scope appears, go back to the Plan before generating an assessment.
  • If too many Requirements appear as fallback rows, improve Requirement to Use Case links upstream.
  • If no Test Cases are linked, decide whether derived test classification is acceptable for this estimate.

4. Generate a Scope Assessment

Pages used: Planning Scope page

Open the Assessment tab and use Generate. Generation runs in the background. If the page does not update immediately, click the AIKOZO logo in the top bar and use Background jobs to confirm whether the job is queued, running, completed, or failed.

For the Scope profile method, generation produces:

  • separate Full Scope and Active Scope analyses, each with readiness, confidence, drivers, missing information, and a min/most-likely/max estimate
  • a zero Active Scope estimate when every Scope Item is deferred
  • classifications for every Scope Item, including deferred items
  • a canonical deterministic effort split: active effort across active items and the Full-minus-Active delta across deferred items, with exact reconciliation
  • estimation profile key, version, and snapshot information when available

Generation does not accept the estimate automatically. The generated assessment is a review candidate until a Planner or Admin accepts it.

Task-based profile calibration and generation

The Tenant Estimation Profiles editor shows task definitions as compact, expandable rows with their factor and counting unit. Open a row to change its Enabled checkbox, metadata and boundaries. Minimum, Most likely and Maximum unit rates sit together on a separate three-column row, with aligned numeric cells for calibration.

Each profile uses one Estimation method. The form shows Scope size ranges for Scope profile, or the task catalog and rates for Task-based. Complexity, ambiguity, risk, missing-information, reuse and confidence settings remain available for both methods. Switching methods preserves entered values, including hidden settings; the method changes when you save the profile.

An Admin duplicates an Estimation Profile, selects Task-based, and calibrates every enabled task type in the profile's effort unit. Definitions include their factor, counting unit, standard boundary, assumptions and overlap exclusions. Built-in definitions have no numeric rates. Disable unused types or provide finite, ordered minimum/most-likely/maximum rates; likely must be positive. Custom types belong to one existing factor. Save the calibrated profile, then select that profile on the Plan. Existing Plans keep their chosen method when the tenant default changes.

Generation uses the profile and rates captured when the assessment was queued. It produces concrete owned work entries, quantities, per-item uncertainty, physical inventory and coverage gaps. Quantity times unit rate, owning-factor complexity and item uncertainty calculates each entry once. Scope-size bands and aggregate functional complexity do not affect task-based effort. Physical inventory is evidence and adds no effort. Composite packages include their contents once. Unsupported or out-of-boundary work needs a suitable calibrated classification; increasing complexity alone cannot resolve it.

The same background assessment action is used. A compatible v3 prompt must be published and mapped by an Admin during the reviewed release. Valid output with unknown counts completes generation with Incomplete costing, known subtotals and specific gaps. Acceptance, numeric overrides and allocation require complete Full costing. An empty Active Scope costs zero. Shared work stays in Active while its owner or any consumer is active, even if its owner is deferred.

5. Review Scope Items and assessment drivers

Pages used: Planning Scope page

Use the Scope Items tab to answer: "What is this scope broken into?"

Each row represents either:

  • a primary Use Case, or
  • a fallback Requirement when that Requirement is not linked to any Use Case

For each row, review:

  • UI, backend, data, integration, security, and test factor levels
  • evidence text explaining why the factor levels were assigned
  • factor pills, where Admins and Planners can click the left half to decrease a factor level or the right half to increase it; the change saves directly and recalculates the item and Scope estimates for both estimation methods
  • the combined Decision detail with provenance and reason
  • the combined Effort detail with canonical Full and Active contributions
  • the Defer or Restore action when a scope item should move out of, or back into, active planning scope without editing the source artifact; both actions require a reason

Each Scope Item uses a two-row group. The item label and Action span both rows; the first row contains Decision, Effort, and Evidence, while the second row shows all six factors across one merged detail cell. Linked Requirement and Test Case counts are omitted so the decision-focused data fits without horizontal scrolling.

Both Scope Items views keep their column layout and use the shared item colors and border highlighting on hover or keyboard focus. In the detailed view, both rows highlight together.

With Task-based, factor pills change complexity while preserving itemized work quantities and artifacts. Each click records the previous and new levels in review history. Use Edit to change the full work breakdown. If a correction was saved but recalculation failed, use Edit → Retry saved correction on that item before making another factor change.

With Scope profile, changing any item factor recalculates that item's canonical Full and Active effort contribution and rolls the delta into the Scope estimates. Contributions of other Scope Items remain unchanged; effort is not redistributed to preserve the previous total. Setting a factor to none therefore removes that factor's calibrated contribution from the item. Existing allocations and downstream Minimum Baselines are marked stale for audit. They remain usable, but may not reflect the changed factor values.

Review measurable work

Task-based rows show compact factor enumerations, such as tables: 3 and views: 8, with a separate line for each task type and its counting unit. Unknown counts appear as ?, and known zero remains 0. Shared work appears on its consumers with a Shared work label; its tooltip names the owner, where effort is counted once. A non-empty factor with no owned or shared task entries shows No itemized work; use Edit to add the evidenced work or correct the factor. Factor levels alone do not establish quantities.

Rows also show Full/Active contributions and physical inventory. Deferred owners show retained shared dependency effort. The Edit button in the Action column opens Edit breakdown, where Planners/Admins correct one Work area at a time. Six compact area tabs show each factor's work count and mark areas that need attention. Switch directly by clicking a tab or using the Left/Right arrow keys; Home/End select the first/last area. Tabs wrap on narrower screens; the selected tab labels its panel without a repeated area heading. Expand a work entry to edit its task type, quantity state, quantity and evidence. Unknown and known zero remain distinct states.

Costing blockers appear first under Needs attention. Use Review issue to open the relevant area and field; coverage warnings remain in a separate collapsed section. The saved issue list updates when you check the estimate. Add UI work, for example, adds an entry to UI and requires an explicit choice from that area's enabled task types. It does not select a task on your behalf.

Factor level is always visible in the selected area. Work appears once as editable entries, initially collapsed, with no separate Saved work link list. Area counts include referenced shared entries. Work links and specialist review remain available in the main Scope Items view.

Generated values and Boundary and package details keep supporting information out of the main editing path. All details within a work entry start collapsed, including entries with costing issues. Review issue and validation open the relevant fields; newly added work opens for editing. Scope details contains inventory, uncertainty and coverage notes. Source references and shared consumers remain available in the entry's details. Revalidation appears only when sources or task definitions changed; review them for all work in the item before confirming. The editor keeps the title, close control, estimate results and Cancel, Check estimate and Save actions visible while the form scrolls.

Generation identifies planned catalog work from the specified behavior across UI, backend, data, integration, security and testing. Explicitly described forms and other units can be counted before implementation. When supported work is identified but its count is unclear, its work entry retains an unknown quantity and a sizing gap for review. Missing catalog coverage remains a gap; test counts alone do not represent the implementation effort. Overlapping broad and narrow Use Cases retain explicit shared-consumer references rather than losing the narrower item's work coverage. Updated prompt instructions apply to new assessments after the v3 prompt is published in the effective Settings scope; existing assessments retain their saved breakdown.

Enter a Reason (required) explaining the correction, then use Check estimate to recalculate without saving. The footer compares saved and proposed Full Scope and Active Scope effort and identifies remaining gaps and manual override retirement. Required fields are marked. Empty risk or missing-information entries must be completed or removed; a known quantity must be a whole, non-negative number. Unknown quantities may remain unknown. Invalid fields show correction messages and receive focus before the estimate check is sent. Server errors remain visible inside the editor.

The footer explains the next step and why Save is disabled. A successful check enables Save; changing any field requires a new check. Valid corrections to a generated assessment can be saved while costing remains incomplete, so you can resolve gaps gradually. Accepted assessments must preserve complete Active Scope costing; gaps confined to deferred work may remain. Save requires a reason and an estimate check that matches the current draft. Count, factor or costing edits retire affected numeric overrides and restore saved-rate contributions. Inventory/evidence-only changes preserve numeric overrides. Generated proposals and before/after review history remain available. An accepted edit must preserve complete costing and refreshes the Scope/Plan baseline; previous allocations and Minimum Baselines display freshness warnings.

Reviewed input persists on the Scope and overrides later generated proposals for unchanged sources and definitions. Changed sources, including shared consumers, or used task definitions require explicit revalidation. Rate-only changes keep counts and take effect in a new assessment. A concurrent edit returns a conflict; refresh before a new correction. If saving reports a saved correction with pending derived updates, use Retry saved correction with the original payload; the pending review can also be reopened after a page reload.

Then return to Assessment. Its compact estimate cards emphasize most likely effort and range, with labelled readiness and confidence. Matching Full and Active Scope metrics appear once under Full & Active Scope; different estimates or quality indicators remain side by side. Incomplete costing shows Known subtotal for either scope instead of an empty Active estimate. The acceptance warning still explains what needs resolving.

The profile appears as one line with its name and version; hover for its key and system/custom origin. The header status replaces the duplicate Review status card, and the obsolete Review note card is removed. Compact panels below retain effort drivers, risk drivers and missing information for Active Scope.

Deferring a Scope Item is a planning-domain decision only. It stores a durable overlay on the Planning Scope, leaves Requirements, Use Cases, and Test Cases unchanged, and marks accepted planning outputs stale. Those outputs remain usable; the freshness warning explains that they may not reflect the latest decision. The UI does not claim an immediate saving before the Active Scope estimate is regenerated and reviewed.

The Scope Overview starts with one estimate state: Accepted · current, Accepted · needs update, Risk accepted, No accepted estimate, or Superseded Scope. The pill's tooltip explains the state and is also available to screen readers. When inputs have changed, a short message explains the next step and Review assessment opens the Assessment tab.

Active Scope effort appears once, with its most-likely value, unit, and range. Estimate details contains Full Scope and deferred effort when they differ from Active Scope, plus the estimation profile and any review note. Empty notes are omitted. Coverage below shows planning items, Requirements, and Test Cases; coverage gaps remain visible. Source Epic identity stays in the page context instead of appearing again as a summary card. Refresh Coverage refreshes source links, not the accepted assessment.

When the Scope has source drift, Specification changes under Scope Coverage lists added, removed, and changed artifacts. Expand an item to compare its assessment basis with the current source, field by field. Older assessments may have only partial snapshots; the preview identifies missing historical detail. New assessments retain full source fields for this comparison.

Planner, Manager, and Admin can choose Accept change risk, enter a reason, and press Accept change risk in the modal to confirm the decision. This keeps the accepted effort and records the actor, time, and reason in Timeline. The estimate becomes Risk accepted, not recalculated or automatically current. Role Work Plan can use this acknowledged source basis when its other readiness requirements are met; the acknowledgment is retained in its source snapshot. Existing saved work plans still require an explicit shared-source refresh.

The decision applies to the reviewed assessment and Scope revisions. New changes detected through Refresh Coverage, new assessment content, or Scope feedback invalidate it. Refreshing the drift preview checks the latest source content; changes between preview and confirmation reject the decision. Scope-item deferrals/restorations, pending corrections, and incomplete costing cannot be waived through this action. Existing Minimum Baseline freshness remains independent. Managers have Planning read access and this specific risk decision; other Planning edits remain restricted to Planner/Admin, within existing tenant, Project, and feature restrictions.

Decision guidance:

  • high effort with weak evidence should be reviewed carefully before acceptance
  • missing information is a planning risk, not just a note
  • low confidence is a signal to improve source artifacts or clarify the work with its owner
  • Scope Items are classification evidence, not the Effort Allocation output

6. Accept or supersede the assessment

Pages used: Planning Scope page

Check the generated estimate and Scope Items evidence, then use Accept to make the assessment the Scope baseline. Supersede retires it. Assessment no longer shows Review or Override buttons; existing notes and estimate history remain available. If the latest assessment is already superseded, Supersede targets the remaining accepted baseline.

Scope Items starts with the detailed table and lowercase filters: *, active, deferred, needs costing. Its compact summary shows item counts and work approval progress. The toggle on the right switches to Simplified view: Scope item, Final text, Gaps, Reviewer and clickable Work items. Final text previews the related specification artifact using the same 220-character limit as Allocation. Approval attribution below each work item is smaller and italic. Hovering or focusing an item highlights its bottom border. This view offers * and assigned to me, combined with a separate Gaps filter: * (all items, including those without gaps), error, or warning. For example, select assigned to me and error to focus on your assigned items with blocking gaps. Items with both errors and warnings match either gap level. Changing one filter keeps the other selection; switching views resets both filters to *. Assigned items include work you review through a shared dependency. Open the same work links in either view to inspect, assign, correct or approve work. A combined summary opens the existing chooser. With no signed-in reviewer identity, assigned to me is unavailable. Detailed view restores decisions, effort, factors and evidence. Pending corrections and stale estimates retain a concise notice above the filters.

For task-based assessments, Generated means the AI job finished; it does not mean costing is complete. Missing quantities, missing measurable work, unresolved package overlap, standard-boundary errors, uncalibrated task rates and required source revalidation block Accept when they affect Active Scope. Gaps confined to deferred work do not block acceptance. Shared work still needed by an active consumer must be costed even when its owner is deferred. After changing defer/restore decisions, regenerate the assessment so its Active Scope reflects those decisions. Needs costing continues to include deferred items for visibility. Full Scope and Plan totals remain incomplete where those gaps exist; known subtotals are not complete estimates. Active Scope specification and role allocations remain available. Full Scope allocation, numeric overrides and Minimum Baseline calculations still require complete Full Scope costing. Use Scope Items → Edit → Check estimate → Save to resolve those errors. The simplified view provides Edit breakdown beside gaps. Hover or focus a gap icon for the issue and its resolution guidance. Errors use red; conceptual coverage warnings use the shared warning treatment.

Free-text Coverage gaps are non-blocking review notes. For example, missing provider details or unclear lifecycle behavior call for clarification with the requirement owner. Open the linked Use Case or Requirement and update its missing behavior or constraints. Add a new Requirement or Use Case only when new scope is needed. Update affected work quantities and regenerate after source changes. A warning never supplies a missing quantity. Quantity edits do not remove notes; use Remove resolved note only once the note is resolved. Saving a correction still requires a reason and a fresh server-calculated estimate check. Actual costing errors highlight the affected factor sections and issue summary in red. Task-rate changes require an Admin to update the Estimation Profile and a new assessment using that profile.

Previously saved assessments keep their saved costing result. Regenerate them to apply the non-blocking coverage-note rule. After saving corrections, check the resulting estimate and Accept it in Assessment. Changed Scope feedback requires regeneration; retry a pending saved correction before acceptance.

What to expect after acceptance:

  • the accepted assessment becomes the Scope baseline
  • previous accepted assessments for the same Scope are superseded
  • the parent Plan rollup is recomputed
  • freshness warnings appear when inputs changed; they are informational and do not block planning actions
  • the assessment remains auditable in history and filterable timeline details

Accept only when the estimate is credible for planning. Keep correction reasons clear enough for a later reviewer.

7. Generate and review Role Allocation and Specification Allocation

Pages used: Planning Scope page

Open Roles after an assessment has been accepted to generate and review the role split. Until then, the page shows Accept an assessment before role allocation. Open Allocation for the specification artifact split; until an assessment is accepted it shows Accept an assessment before allocation.

The Planning Scope page has two allocation views:

  • Role Allocation first divides every active Scope Item contribution across its six non-none factors, then divides each factor bucket only among roles eligible for that factor. Delivery Role Profile weights and factor adjustments determine the split inside each bucket. A none factor contributes zero; for example, when every test factor is none, no Tester role is allocated. It does not create independent role estimates. The profile key, version, snapshot, factor allocation, and factor reconciliation are stored for audit.
  • Specification Allocation selects a Full or Active basis (Active by default). Full includes all lineage; Active excludes deferred lineage. It is an optional artifact view, not a Minimum Baseline prerequisite.

Use Generate Allocation on Roles when you need a role split for planning and review. Use Generate Allocation on Allocation when you need traceable effort guidance by specification artifact. Both paths reconcile back to the accepted Scope estimate, so the sum of allocated role effort matches the sum of allocated specification effort for the same accepted assessment.

Review:

  • accepted assessment estimate and Plan-associated Delivery Role Profile
  • factor-proportional role shares, effort ranges, factor rationale, confidence, the factor-to-role effort matrix, and CSV export when needed. Matrix rows are factor effort buckets, columns are delivery roles, and role totals are column sums. Hover a matrix row label or its level counts to see that the counts are active Scope Items at each factor level and that their effort is shared across eligible roles. Deferred Scope Items are excluded from these counts. The CSV exports each role's total allocated effort and share once. The compact matrix headers use BE Developer and FE Developer.
  • allocation target: automatic, Use Cases, Requirements, or Test Cases
  • allocation method: factor weighted or equal
  • total allocated effort
  • reconciliation status
  • linked artifact rows, final text, item weights, factor effort buckets, and CSV export when needed

What to expect:

  • if no role allocation exists yet, the page says No role allocation generated yet.
  • if no allocation exists yet, the page says No allocation generated yet.
  • generated role allocation and specification allocation totals should reconcile to the accepted estimate
  • Factor-weighted Specification Allocation and Role Allocation use the same canonical factor-effort-bucket calculation. Generation stops explicitly when an active Scope Item has missing/invalid factors, all six factors are none while the item has effort, or canonical item effort does not reconcile to Active Scope; no equal fallback is applied
  • small rounding residuals are applied to the final item
  • each item shows factor effort buckets across UI, backend, data, integration, security, and test; low/medium/high classifications redistribute the item allocation while preserving the item total
  • accepted allocations are planning guidance, not delivery commitments

Task-based allocation and export

Task-based Role Allocation shares the canonical factor ledger with existing eligible roles and Delivery Role Profile weights. Counts remain whole evidence quantities. Its matrix counts include deferred owners whose shared work remains active. Specification Allocation defaults to Scope Items, covering primary Use Cases and unlinked Requirements, with Task-based as the method. Explicit Requirement or Test Case targets use validated lineage and name uncovered work when the target cannot represent the full contribution. Equal is an explicit alternative that conserves both factor and Scope totals.

Both CSV exports use the saved allocation snapshot. The Allocation tab exports each owned task's quantity and effort once, plus descriptive inventory. It omits item and factor summary rows and audit metadata, so effort columns can be summed without duplication. Its columns are Artifact, Factor, Task type, Counting unit, Quantity, Complexity adjustment, Item uncertainty multiplier, Minimum, Most likely, Maximum and Unit. Inventory rows add no effort.

The Roles tab exports one row per delivery role from its saved role allocation, for both task-based and factor-based estimates. Its columns are Delivery Role, Share, Minimum, Most likely, Maximum and Unit. Share is the saved allocation fraction (for example, 0.25 means 25%). Effort columns contain each role's total once and can be summed; task quantities, factor summary rows, inventory and audit metadata are omitted.

Role Work Plan: forecast role demand

Open a Plan and select Role Work Plan, immediately after Scopes. Planner and Admin can edit; Manager has read access. This forecast does not change Plan acceptance, Scope assessments, role allocations, or the Minimum Baseline.

The scenario selector starts a single row followed by the scenario buttons, without a separate label. Export is in this toolbar; Delete is the final action, separated by a divider and styled as destructive. On narrow screens, the toolbar scrolls horizontally. Setup and sources starts collapsed and contains coverage, assumptions, source readiness, editing actions and the inline editor. Coverage counts, timing, and conversion assumptions are grouped in summary cards; source rows separate names, status, blocking reasons, and open links. The source, timing, and scenario editors share the same spaced form layout with a separate review/save action row. Starting an edit opens it automatically; collapsing it preserves unsaved edits. Needs update on the toggle flags stale sources; its tooltip explains what changed and directs you to Update shared sources to refresh all scenarios. The demand filters and table follow directly below the setup section, without an extra section gap. Estimate range and Display use compact filter-button groups beside the Filter roles search field. The selected options are highlighted and also apply to CSV export. The Human effort tooltip explains the totals and human/automation distinction. Period navigation sits at the bottom-right of the statistics row.

If a Scope is Not ready, expand Setup and sources to see its blocking reason in Source coverage and readiness. Open Assessment takes you to the assessment when its inputs or decisions have changed. An accepted assessment can still be stale: generate and accept a new assessment, then generate and accept its role allocation. For source drift only, you can instead review Specification changes on the Scope Overview and Accept change risk with a reason. Other readiness gates still apply. Refreshing the page or lineage does not regenerate or accept estimates. Return to Role Work Plan to reload readiness after completing these steps.

  1. Choose New scenario, enter a unique name and a duration in working days or working weeks. On first creation, select ready Scopes and review the two separate conversion assumptions: Estimate hours per person-day and Hours per full-time working day, both initially 8. A ready Scope is active and has a current, complete, accepted assessment and an accepted, reconciled role allocation.
  2. Optionally enable calendar dates. Use a working start date plus either a duration or an end date. Working weekdays default to Monday–Friday; there are no automatic holiday exclusions. Enter excluded dates explicitly. Relative timelines use Week 1, Week 2, and so on; monthly aggregation requires dates.
  3. Preview and save. The initial distribution is even. Use Edit timing to expand a Scope and set its working-day window or role overrides. Positions start at 1 and both displayed endpoints are included. Earlier uses descending daily weights; Later uses ascending weights. No delivery phases are inferred from role names. When changing duration, choose to keep working-day positions or scale all custom timing. Invalid windows must be corrected before saving.
  4. Read the numeric role-by-period table. Select Minimum, Most likely, or Maximum; switch between average FTE and effort hours; filter roles; and inspect a cell for contributing Scopes and daily peaks. Role filters do not change totals or saved Scope inclusion. Previous/next controls page through the horizon. FTE means full-time-equivalent demand, not unique headcount or a delivery commitment. AI Agent effort is separate; Human Reviewer remains human effort.

Select a role name to open its weekly distribution editor. Weeks run down the modal; moving a horizontal slider right increases that week's allocation. The editor uses Most likely, with average FTE or hours for human roles and hours for automation. The accepted effort stays fully allocated. Numeric table cells still open the contributing-Scope inspector. It groups each Scope into a card with labeled effort and FTE metrics, distribution and assessment badges, and timing details. Select an available Scope card to open its Roles tab. Automation cards show effort hours only; unavailable sources remain readable.

Hour readouts in the matrix, distribution editor, Scope inspector, previews, and CSV are rounded to the nearest half-hour: 8.878 h → 9 h, 8.74 h → 8.5 h. Quarter-hour ties round up. FTE readouts throughout Role Work Plan and CSV use up to two decimal places: 2.135 → 2.14, 0.396 → 0.4. Calculations and saved distributions retain their existing precision. Totals are calculated before display rounding, so rounded rows may not add up; very small amounts can display as zero. Focus a numeric field to see and edit its exact value. Focusing and leaving it unchanged does not round or redistribute any effort.

Changing a week marks it Held. Other Auto weeks absorb the change in proportion to their current effort, within each contributing Scope's timing window. Held weeks retain their Scope contributions. A zero that you enter is held at zero; an entirely empty Auto pool receives effort by eligible working days. Partial weeks therefore need not receive equal hours. Values above one FTE are allowed: this is demand, not a staffing-capacity limit.

Use the number field, plus/minus controls, or slider arrow keys for precise adjustments; Fine adjustment reduces the step. Undo and Redo restore whole changes, including affected Auto weeks. Releasing a hold does not move effort immediately. Restore saved returns to the opening saved shape; Use timing defaults removes custom distribution and restores existing Scope/role curves. Zoom out, Fit allocation, and Jump to week only change the view. Auto weeks outside the visible area still participate. Open How redistribution works → Edit timing to review the Scope windows; unsaved distribution changes use the usual discard confirmation.

Each completed edit automatically requests a preview. Save distribution becomes available after that exact draft is validated; it updates this role in the selected scenario. Cancel discards the draft. A conflicting revision requires an explicit reload, and a failed save with an unknown outcome must be retried before editing further. Read-only users and stale scenarios can inspect the distribution. The modal groups totals in summary cards and shows a specific read-only explanation when editing is blocked. For stale sources, close it and open Setup and sources → Update shared sources, review and save the update, then reopen the role. This also applies in local development with authentication disabled: source freshness is independent of permissions. The refresh can affect all scenarios sharing those sources.

Custom shapes and holds are copied with a scenario. Shared-source updates preserve matching relative shapes and show changes to Held amounts before saving all scenarios. Calendar/window edits release holds whose working-day sets change; the preview reports them. Keeping positions leaves newly added days empty for custom profiles; scaling conserves their effort over the new timing window. Invalid or truncated profiles must be corrected explicitly.

Named scenarios have independent calendars and timing. Switching preserves scenarioId in the Plan URL and protects unsaved edits. With no selection, the first-created scenario opens; it is not marked approved or preferred. Duplicate opens an unsaved copy of timing and assumptions and requires a new name. Names are unique within the Plan without regard to letter case. Deleting the last scenario retains the shared source setup. There is no comparison screen.

One shared source basis applies to every scenario. Scope inclusion, accepted estimate snapshots, role classification, and conversion assumptions are shared. Included, ready-but-excluded, and not-ready counts describe coverage, not an estimated percentage of effort. A partial forecast must not be read as the whole Project's resource requirement.

Use Update shared sources to preview accepted estimate changes, removed Scopes/roles/overrides, and the impact on every scenario. The editor separates Scope selection, conversion assumptions, and review actions. Select a Scope by its checkbox or name; Open Scope opens its details independently. Saving applies the change atomically to all scenarios. Matching timing is preserved. New Scopes span each scenario's horizon; new roles inherit the Scope window with even distribution. An invalid source must be corrected upstream or explicitly removed. Removing all sources is allowed after initial setup and produces an empty demand forecast.

Changed or deleted sources make all saved scenarios stale. Saved demand remains readable and exportable with warnings. Refresh or explicitly remove invalid sources before changing timing; renaming and deletion remain available. A conflicting save preserves the current server revision and asks you to reload and review. Scope deletion keeps saved estimates as unavailable historical provenance; deleting the Plan deletes its Role Work Plan.

Export in the scenario toolbar downloads a CSV matrix matching the table: one row per filtered role, a column for every period across the complete horizon, then Total hours, Horizon-average FTE, and Peak daily FTE. It uses the selected estimate range, display mode, aggregation, and interface language. The Human total row still covers all human roles. Automation cells remain hours, with no human FTE. Values use the same half-hour rounding for hours and two-decimal precision for FTE; this is a presentation export, not an exact accounting ledger. Detailed metadata and source snapshots are omitted.

The export uses the expected saved revision, including when unsaved edits are open. Stale-source warnings remain in the UI; exporting does not refresh the saved data. Spreadsheet formula prefixes are neutralized.

Available capacity, shortages, named people, automatic scheduling and scenario comparison are outside this version.

8. Generate and review the Minimum Baseline

Pages used: Plan detail page

For task-based estimates, Minimum Baseline costing uses the unique work ledger. An included consumer retains shared dependency effort even when its owner is deferred; source-artifact classifications remain unchanged. Feature Projection attributes each shared contribution once across its candidates.

After each active Scope has a current accepted dual assessment, return to the Plan detail page and open Minimum Baseline. Specification Allocation is not required. Use Generate to create an immutable deterministic revision from the accepted assessments and canonical Scope Item splits. This does not call AI and it does not delete or change Requirements, Use Cases, Test Cases, Scope Assessments, or allocations. It stores a snapshot so later source edits do not rewrite historical baselines.

Classifications:

  • included: mandatory or core evidence exists, such as high or critical priority, accepted/final core workflow evidence, security, audit, compliance, or explicit required language.
  • required dependency: the artifact supports an included item through Requirement, Use Case, Test Case, or approved dependency graph links.
  • Deferred from this Minimum Baseline: explicit optional, nice-to-have, secondary, reporting, or advanced-filtering evidence exists and no mandatory or dependency evidence exists.
  • excluded: explicit out-of-scope, obsolete, deprecated, or cancelled evidence exists.
  • decision needed: allocation or assessment data is missing, evidence conflicts, compliance/security ambiguity exists, or evidence is insufficient. Silence alone does not defer an item.

Reconciliation applies to min, most-likely, and max:

  • Full Scope = Active Scope + explicit planner-deferred effort
  • Active Scope = Minimum Baseline + baseline-deferred + excluded + decision-needed
  • Planned reduction includes explicit deferred, baseline-deferred, and excluded effort; it never includes decision-needed effort
  • incomplete cost or a non-zero residual blocks acceptance

The four compact summary cards present Full Scope, current Active Scope, the current Minimum Baseline target, and Planned reduction with a prominent range and a separate most-likely value.

The Scope reconciliation section separates effort disposition from arithmetic. Five compact breakdown tiles show the effort and item count held in the Minimum Baseline, then moved by planner deferrals, suggested or accepted deferrals, exclusions, and unresolved decisions. Supporting audit information is grouped under Baseline details so the primary estimates and decisions remain easy to scan. Expand it to see source assessments, classification counts, review notes, and separate Full Scope balance and Active Scope balance checks. They show a green Balanced state when the corresponding residual is zero; a non-zero residual is highlighted as a variance that needs review. This keeps unresolved effort visible without presenting it as a planned reduction.

Suggested for later and Excluded use the immutable Minimum Baseline revision. Deferred by planner uses current Scope Item decisions and sums their canonical Full Scope contributions. The current Active Scope, Minimum Baseline estimate, Planned reduction, and In Minimum Baseline card are projected from those current deferrals. Decision needed uses open Savings Opportunities whose backend validation is decision_needed, summing the indicative ranges that are available. Its helper text states how many opportunities have quantified effort. Applied opportunities leave this bucket and are represented by the resulting deferred Scope decisions. Balance checks continue to use immutable revision totals.

Acceptance may continue with decision-needed effort only after warning confirmation. Generated, reviewed, and accepted revisions are immutable. Decision or coverage changes mark them stale for audit, but do not require a new revision before continuing. Generate a new revision when the latest inputs need to be reflected.

The canonical unit is person_days or person_hours. Every reconciliation bucket retains the assessment profile unit; the UI displays these as person-days or person-hours without converting between them.

Use Review when the generated baseline has been checked, Accept to make it the current Minimum Baseline for the Plan, and Supersede when the baseline should no longer be current. Accepting a new Minimum Baseline supersedes the previous accepted Minimum Baseline for the same Plan. Superseding is not deletion; old baselines remain audit records.

Open Design verification and use Generate in Design-informed Confidence when a final Implementation Design exists and you want to check whether the Minimum Baseline is still credible against the architecture. The review reads persisted Implementation Design fragments and the Patterns selected or allowed by that Design. It does not read Flow Designs, Features, Execution Targets, Action Packs, Instruction Sets, Build Runs, JIRA tasks, or implementation tasks, and it does not mutate Design or Pattern records.

The Design-informed Confidence result stores architecture fit, Pattern fit, reuse evidence, architecture-related effort and risk drivers, missing architecture information, baseline realism notes, referenced Design fragments, referenced Patterns, recommended confidence, and whether confidence should increase, decrease, or stay unchanged. Recommended confidence is guidance for human planning review; it does not recalculate effort, overwrite accepted Scope Assessments, overwrite accepted allocations, or change the accepted Minimum Baseline. Planner and Admin roles can generate, review, accept, supersede, or refresh these reviews. Accepted reviews create an auditable confidence checkpoint before the later Feature Projection phase.

Design-informed Confidence generation runs as a background job. Open Background jobs from the AIKOZO logo to see whether the Design Confidence job is queued, running, completed, or failed. When the job finishes, refresh the Design verification tab if the review has not updated yet.

The Minimum Baseline tab can also generate Savings Opportunities for an existing Minimum Baseline. These are AI-assisted suggestions that answer where the Plan might reduce implementation effort while preserving required scope. They do not replace deterministic baseline generation: AI only proposes candidates, and the backend validates artifact references, mandatory scope protection, dependency protection, classification safety, tenant/project scope, and all saving calculations before anything is shown.

Use Generate to queue the AI prompt as a background job. The button shows Generating... while the job is being started. Open Background jobs from the AIKOZO logo to see whether the Minimum Baseline savings job is queued, running, completed, or failed. When the job finishes, refresh the Minimum Baseline tab if the table has not updated yet.

Savings Opportunities can use these suggestion types:

  • defer: move clearly optional scope out of the Minimum Baseline.
  • reduce: narrow clearly optional scope while keeping required behavior.
  • split later: keep required behavior now and move secondary behavior later.
  • decision required: highlight ambiguity that a Planner or Admin must resolve before treating it as a saving.

Each opportunity is tied to artifacts already present in the Minimum Baseline or accepted allocations. Savings are calculated only from existing allocation item estimates and are shown as Indicative saving. If an artifact is mandatory, security/compliance/audit critical, a required dependency, part of an accepted core workflow, or unclear, the backend can still show the indicative effort attached to the affected artifact while marking the opportunity decision needed. If an artifact has no allocation estimate, there is no indicative saving to show. Opportunity suggestions do not delete, defer, or mutate Specification artifacts; Planner/Admin review remains required.

When a Savings Opportunity maps affected artifacts unambiguously to Planning Scope items, Defer all records the decisions and marks the opportunity applied. It never rewrites the source Minimum Baseline. A stale accepted baseline may still be used for Savings, Design Confidence, Feature Projection, and Extension generation/apply actions. The UI keeps the freshness warning visible because those outputs may use older inputs.

9. Project Feature Candidates

Pages used: Plan detail page

After a Minimum Baseline is accepted, open Feature Candidates. This tab answers which Implementation Features should be created from the accepted baseline. Generate queues a background AI job that creates a Feature Projection Proposal from the accepted Minimum Baseline, Baseline Items, linked Requirements, Use Cases, Test Cases, accepted Specification Allocation, Role Allocation evidence when available, the accepted Design verification result, Implementation Design fragments, and the Patterns selected or allowed by that Design. Track the job in Background jobs; the tab refreshes after the job completes.

Feature Candidates are not Flow Designs, Action Packs, Instruction Sets, delivery tasks, execution routing, or code. They are reviewable implementation feature boundaries with traceability back to the Plan, Minimum Baseline, proposal, candidate, Baseline Items, Scopes, Requirements, Use Cases, Test Cases, Design fragments, and Patterns.

The tab shows proposal status, coverage summary, unassigned Baseline Items, inherited effort, and the generated Feature Candidate list. Warnings are grouped in a collapsed disclosure with a visible count; expand it to review validation and traceability concerns. Open a candidate to review the Feature Candidate detail page. Its tabs separate Risks and decisions, Included in scope, Required dependencies, and Design fragments. The detail page also shows additional traceability to Requirements, Use Cases, and Test Cases, plus Patterns and created Feature links after apply. Unassigned Baseline Items are eligible accepted-baseline items that were not placed into a Feature Candidate; review them before accepting a proposal.

Planner and Admin roles can generate, review, accept, and supersede Feature Projection Proposals. Apply is restricted to Admin in the current UI/API. Apply only works in two safe modes:

  • create a new Implementation and create Features there
  • use an existing Implementation only when it has no Features

Feature Projection protects populated Implementations. If the selected Implementation already contains Features, apply is rejected, no Feature is created, and existing Features are not overwritten or merged. Applying a proposal never mutates the accepted Minimum Baseline, Specification artifacts, Design artifacts, Pattern definitions, Flow Designs, Action Packs, Instruction Sets, or execution artifacts.

10. Review Remaining Scope and Extensions

Pages used: Plan detail page

After Feature Projection has been applied, open Remaining Scope. The tab compares Plan Scope lineage with created Implementation Feature traceability to show what has already been projected and what remains outside the projected Implementation. Coverage is calculated from applied Feature source references, not manual checkboxes.

The dashboard shows projected Requirements, Use Cases, Test Cases, and effort where allocation estimates are available. Effort coverage uses stored planning allocation and baseline estimates; if some artifacts lack numeric effort, the tab still shows count coverage and displays a warning instead of inventing an estimate.

Artifact states mean:

  • projected: already covered by created Features from applied projections
  • remaining: eligible for a later Extension
  • deferred: intentionally deferred in planning
  • decision_needed: blocked until a planner records a decision
  • excluded: explicitly excluded from the current baseline
  • blocked: missing traceability, allocation, or other prerequisite data

Planner and Admin roles can select remaining or deferred artifacts and create an Extension. Extension items keep their source Scope, baseline item when available, allocation estimate, and original artifact snapshot. Already projected artifacts cannot be selected again, and artifacts outside the Plan lineage are rejected by the backend.

An accepted Extension can generate its own Feature Projection Proposal using the same Feature Candidate mechanism as the Minimum Baseline, but with source_type recorded as extension. Extension projection preserves traceability to the Plan, Extension, Extension Items, source baseline items when available, Scopes, Requirements, Use Cases, Test Cases, Design fragments, and Patterns. It does not create Flow Designs, Action Packs, Instruction Sets, execution artifacts, or implementation tasks.

Applying an Extension differs from applying the Minimum Baseline. Baseline projection can still apply only to a new Implementation or an existing Implementation without Features. Extension projection may also apply to an existing populated Implementation only when every existing Feature is traceable to prior accepted or applied Feature Projections from the same Plan. The backend rejects unrelated, mixed, untraceable, or duplicate artifact targets atomically.

Task-based Extension cards show effort from the selected saved work ledger. Shared dependencies are counted once, including those owned by an unselected deferred item. Work already included in the accepted Minimum Baseline adds zero incremental Extension effort. Existing projection/apply permissions remain required.

11. Maintain the baseline as scope changes

Pages used: Plan detail page, Planning Scope page, Tenant Estimation Profiles tab, and Tenant Delivery Role Profiles tab

Planning is a baseline, not a one-time file export. Revisit the Plan when the underlying specification changes materially.

Regenerate or review again when:

  • Requirements or Use Cases are added, removed, or substantially rewritten
  • links between Requirements, Use Cases, and Test Cases change
  • missing information is resolved
  • risk or effort drivers no longer match current understanding
  • a new accepted baseline should supersede the old one
  • the accepted Minimum Baseline no longer reflects current accepted Scope evidence

Use Assessment history, the Planning Scope Timeline, and Plan Versions to reconstruct what changed and why. Current Planning panels hide superseded assessments, allocations, and Minimum Baselines by default so retired candidates do not clutter the active workflow. Use Estimation Profiles on the Tenant page when you need to inspect which deterministic profile version is associated with the Plan for future assessments. Changing the tenant default only changes the preselected profile for new Plans; it does not rewrite existing Plan profile references. Use Delivery Role Profiles on the Tenant page when you need to inspect or manage the deterministic role weights available for Plans. Changing the tenant default only changes the preselected delivery role profile for new Plans; existing Plans and Role Allocations keep their stored profile references and snapshots.

Completion checklist

The Planning flow is complete when:

  • every active Scope in the Plan has reviewed coverage
  • every active Scope that needs planning has an accepted assessment baseline
  • overrides, if any, include clear justification
  • Scope Items evidence has been checked for weak or surprising classifications
  • Role Allocation or Specification Allocation has been generated and accepted when that allocation guidance is needed
  • the Plan-level Minimum Baseline has been generated and accepted when minimum scope optimization guidance is needed
  • Design-informed Confidence has been generated and reviewed when a final Implementation Design should inform planning confidence before Feature Projection
  • Remaining Scope has been reviewed after Feature Projection apply when the team needs a path from the Minimum Baseline toward fuller coverage
  • the team understands that the output is planning guidance, not a delivery commitment

Specialist work review

In Scope Items, activate a work summary such as Web forms: 1 to inspect or edit that work. A combined summary opens a chooser. Shared work opens its owning Scope Item and is counted once in review progress. Use the existing Scope filters and sorting to browse the items. Both views use plural standard task labels with the quantity shown once, such as Web views: 2 or Processes: 1. These summaries are clickable; unit details remain in the work tooltip. The simplified table lists assigned reviewer names, showing Unassigned only when no reviewer is assigned. The work pane shows individual assignments and assessment states. The shared-work prefix remains plain text. Scope Item row actions are Edit and Defer (Restore for deferred items). Use Edit → Work area → Add {factor} work to add entries or address missing factor coverage. Task choices stay within the selected work area.

The focused pane uses the same editing order as Edit breakdown. Costing blockers appear first under Needs attention, with actions to edit the quantity, review details or resolve the issue in the breakdown. The pane shows the named reviewer and human review state separately from costing gaps. Quantity, quantity state and evidence are the main controls; choose Known, Unknown or Not applicable explicitly. Generated values start collapsed; boundary/package details open when a relevant issue needs attention. View sources and Source evidence references start collapsed. Expand their arrow toggles to see wrapping source pills in the usual RQ, UC and TC colors; source links open in a separate tab and preserve the draft. Disclosure controls show a pointer cursor, hover feedback and a visible keyboard-focus outline. In Boundary and package details, Within standard boundary and Package overlap resolved use the standard checkbox rows. Click the label or press Space while the checkbox has focus to change the value. Task type choices remain within the entry's work area and enabled catalog. Assignment uses Change reviewer → Apply and preserves any unsaved costing draft, including an unknown quantity. Eligible reviewers are active tenant members with Planner/Admin access to the Project. A directory error is shown instead of offering an unverified cached list.

Costing edits automatically check the estimate on the server after a short pause. The footer compares saved/proposed work effort and Full Scope/Active Scope totals in compact cards, with each label above its estimate. Remaining gaps and any numeric override retirement appear below the cards. Enter a correction reason, then choose Save, Save partial correction, or Save & approve. An unchanged valid entry can be Approved with an optional note; Save assessment note records assessment without approval. Any authorized Planner/Admin may approve, including someone other than the assignee. The pane always shows who actually approved.

Successful saves and approvals close the pane and return focus to the work link. Cancel, Escape, History and editor switching protect dirty drafts with a confirmation pane. Source links open separately. If work changed concurrently, Refresh and reconcile retains your changed fields against current saved values and requires a new estimate check. If a durable operation is pending, resume that same operation before further edits.

Use Edit breakdown for shared assumptions, inventory, cross-entry packages and explicit source revalidation. Switching from the focused pane keeps its work area selected in the breakdown. Missing work can be added there; coverage gaps have responsibility targets but cannot receive work-cost approval. Assignment does not transfer automatically when new work is created.

Human review states are Needs assessment, Assessed, Approved and Needs reassessment. Approval refers to the reviewed quantities, definitions, rates, sources, relationships and effective cost. Relevant changes require reassessment; unrelated work changes and reassignment preserve current approval. Specialist review progress does not replace complete costing or overall assessment acceptance. Without authenticated human identity, costing can still be edited, but named review actions are unavailable.

The existing Timeline shows newest-first activity without date-group headings. Compact cards show the event summary, actor/action, reason and collapsed Details on the left. The browser-local timestamp sits on the right, with Open work directly below it. Use all, Work reviews, human, ai and status filters and Load more for older events. History opens a work-filtered Timeline; Open work opens the current editor or read-only historical details for removed work. Save & approve appears as separate correction and approval actions grouped together. Links preserve the page's tab, itemId, workId, actorId and action targets.