Planning Tools

The planning record of a project: its epics (the bodies of work the client recognises, each numbered from the project's tracker sequence, CRM-12, with its goal, value, measures, owner, MoSCoW priority, status from draft to done and dates) and its requirements (what the system shall do, functional, CRM-FR-12, and the qualities it shall keep, non-functional, CRM-NFR-3, each with a category and a measure, with the statement, the source, the priority, the verification method and the status from draft to baselined). The business rules sit beside them: the decisions of the business the system must honour (CRM-BR-7), each a constraint, derivation, computation, inference, action enabler or policy in plain words, with when it applies and what follows, exceptions, worked examples, authority, priority and the dates in force. The use cases sit beside them too: how a persona reaches a goal with the system (CRM-UC-4), with the actor and the other actors, the goal, the trigger, the conditions before and after, how often it happens, priority, status and the steps of the main flow with the alternate and exception flows that leave it. The RAID log keeps what may go wrong and what the project leans on (CRM-RSK-4): the risks scored by probability and impact with their mitigation and contingency, the assumptions, the issues and the dependencies, each with its area, owner, dates and status; the log is internal and never read by a guest token. The decisions record every choice the project made (CRM-DEC-5): the context, the options weighed with their pros and cons, what was decided, what follows, who decided, when, and the earlier decision each replaces, moving from proposed to accepted or rejected and from accepted to superseded or deprecated; they are internal too. The links join any two of these artefacts, and the dictionary's entities and terms, with a kind read from the source (a story implements a requirement, a bug is fixed by a story, a decision relates to an epic) and read back from the target (is implemented by), so one record is followed in both directions; they are internal as well. The comments carry the conversation on each of them: a question, an answer under it, a finding, a decision taken in the margin, each open to everyone who sees the artefact or internal and kept from client guests, naming people with @ to tell them, and resolved when the question is settled. The attachments are the files pinned on each of them, wireframes, specifications and samples, kept on a private disk and streamed only to a token that may read the artefact. These tools read the epics, the requirements, the rules, the use cases, the log, the decisions, the links between them, the comments on them and the files pinned on them as the token sees them (a guest token the agreed ones only), draft a story into the backlog under an epic with its sentence and its acceptance criteria, a requirement into the specification, a rule into the rulebook, a risk onto the log and a decision as proposed (drafts a person reviews), link two artefacts with a kind (a repeat is refused, never doubled), post a comment in Markdown on any of them (the people named and the followers are told), read the files pinned on any of them and fetch their bytes over REST, and read every version a save of an epic, a work item, a requirement, a rule, a use case, a RAID item or a decision wrote, with who wrote it, why and the diff from the version before, putting a version back when a person asks; create an epic (create_epic), a use case with its flows (create_use_case) and any RAID item (create_raid_item), change every one of these records in part and move it where the lifecycle allows by hand (update_epic, update_requirement, update_business_rule, update_use_case, update_raid_item, update_decision; the review states go through submit_for_review and the approvers), delete one or remove a link after a confirmation, hand a brief to Heimdall's reader (start_brief_import), read the queue it fills (list_import_batches, get_import_batch) and decide a row or a council finding on the person's word (decide_suggestion, decide_council_finding), start the research sweep and read its notes (start_project_research, list_research_notes), and write who approves what (update_approval_policy). Editing, resolving and deleting a comment, uploading and removing a file, and deciding an approval stay in the application and the REST API. Heimdall's quality reviews of a story, a requirement or a rule are read here too (list_quality_reviews: the score out of 100, its band and the findings, for an agent to read before it builds or tests a record) and asked for (review_quality, which spends the team's AI budget and never changes the record). The baselines and the change requests close the circle: a baseline is a named set of approved records frozen together (the scope the client signs, what a release ships, what a sprint commits to), read with list_baselines and get_baseline (each record it holds, the version pinned and whether it is still locked), composed as a draft with create_baseline, recomposed or superseded with update_baseline, deleted while a draft with delete_baseline and frozen through submit_for_review; a change request (CRM-CR-2) is the one way a frozen record changes, read with list_change_requests and get_change_request, raised with raise_change_request naming the baseline and the records it touches, changed or moved by hand with update_change_request, read by Heimdall for its impact with analyse_change_impact (which spends the team's AI budget and fills only the numbers left empty), deleted while never agreed with delete_change_request, and put to its approvers through submit_for_review, whose approval unlocks the records it names. A record a frozen baseline holds answers every write with BASELINE_LOCKED until then.

ToolsCopy Anchor Link