Status: documented, untested. MktOS sets/reaffirms North Star Metrics and establishes annual OKRs yearly, with quarterly reviews. The monthly/weekly/daily execution rhythm is the current starting configuration for solo marketers and small teams, not a claim of full Scrum adoption.
Read with the MktOS Guide, entities and processes, entity-relationship model, and weekly routine. The catalog defines concepts and responsibilities; this page explains how their planning, delivery, inspection, and adaptation connect over time.
Horizon and review frequency
A planning horizon is how far a decision looks ahead. A review frequency is how often evidence about it is inspected. MktOS establishes North Star Metrics and annual OKRs during yearly planning, then reviews them quarterly. Annual KRs can also be monitored monthly or weekly. A quarterly review does not automatically create another set of OKRs or reset the baseline and target.
Research, diagnosis, and strategy revision occur when evidence or decisions require them, not only at annual planning. The North Star Metric is an enduring scoped customer-value measure, not a target that expires with the calendar year. A Product Goal describes the intended future state of a defined product or service; its time horizon need not match a quarter.
Connected cycles
Participants are responsibilities, not required job titles. One person can hold them all. In a team, name who can make priority/resource decisions, coordinate work, deliver, and assess evidence.
| Cycle | Purpose and trigger | Inputs | Responsible participants | Outputs and updated records | Next connection |
|---|---|---|---|---|---|
| Yearly planning and review | At the annual boundary, assess the prior year and establish direction and annual outcomes. | Market/customer diagnosis, business model, prior outcomes, strategic assumptions, resources. | Priority/strategy decision-maker, planning owner, relevant contributors. | Set/reaffirm North Star Metrics; annual objectives/KRs with baseline, target and source; resource boundaries and aligned Product Goals where appropriate. | Establishes the outcomes reviewed quarterly and pursued through execution. |
| Quarterly outcome review and execution planning | Inspect progress toward the same annual outcomes and select the next execution priorities. | Annual North Star Metrics/OKRs, actual results and forecasts, learning, open commitments, backlog, capacity and dependencies. | Planning owner, priority/resource decision-makers, delivery contributors, result owners. | Reviewed annual OKR health/relevance and forecasts; project/milestone/resource decisions and ordered Product Backlog. Preserve annual definitions, baselines and targets unless a justified strategic change is explicitly recorded. | Prepares monthly inspection and sprint delivery; does not automatically replace annual OKRs. |
| Monthly review and adjustment | Inspect whether the period's plan remains credible. | Current KRs, Increments, Learning Cards, capacity, risks, blocked work and observation dates. | Planning owner with relevant decision-makers and evidence/delivery owners. | Updated independent health assessments; resource/scope decisions; revised backlog, assumptions, A3/Canvas or strategy where justified. | Supplies decisions to the next sprint; triggers a broader replan when needed. |
| Weekly sprint cycle | Deliver a coherent useful result and learn from it. | Product Goal, ordered/refined work, current evidence, Definition of Done/Workflow, actual contributor availability. | People ordering and delivering work; relevant stakeholders for inspection. | Sprint Goal and Sprint Backlog; usable Increments; delivery and outcome decisions; one process improvement. | Sprint Review and Retrospective feed the next Sprint Planning. |
| Daily progress inspection | During active delivery, inspect progress toward the Sprint Goal and adjust the next actions. | Sprint Backlog, actual progress, blockers, remaining capacity and dependencies. | People doing the work; involve a decision-maker when authority is needed. | Updated plan, visible blockers, owner/next action, and an escalation or scope decision where needed. | Continues delivery and informs the next inspection. |
At annual and quarterly reviews, reflect briefly on how planning and collaboration worked as well as what outcomes occurred. Fold that reflection into the same session where useful; it does not create another mandatory retrospective meeting. At every scale, conclude with a responsible person and next action or observation.
Quarterly expected progress, intermediate milestones and revenue forecasts help judge the annual plan; they are not new OKRs by default. Replanning the work is different from changing the outcome. When a material strategic assumption fails, the responsible decision-maker may revise an annual commitment explicitly, retaining the reason and prior record. The calendar boundary alone is not a reason.
Complete sprint flow
The starting configuration uses weekly sprints. Sprint lengths and event time budgets should be explicit and fit real availability. A quarter contains the sprints its actual dates and chosen duration allow; do not assume an exact count.
- Prepare and refine. Keep the Product Backlog ordered. Clarify scope, acceptance criteria, dependencies, and size before selection. Refinement is ongoing work, not an additional mandatory Scrum event. Check the relevant people can actually contribute.
- Sprint Planning. Agree why the sprint is valuable, what can be delivered, and how to approach it. Record the Sprint Goal and actionable Sprint Backlog, using the same work records rather than copying tasks. Include routine work, carryover, and the previous improvement when checking capacity.
- Deliver and inspect progress. Execute, verify quality against the Definition of Done and item acceptance criteria, and adapt the plan as understanding changes. Show blockers and dependencies. A usable Increment can be delivered before the sprint ends; Sprint Review is not a release permission gate.
- Daily inspection. Scrum calls its daily progress event the Daily Scrum. MktOS suggests a brief solo check or team exchange serving that purpose; a shortened or asynchronous adaptation is not presented as an unchanged official Scrum event.
- Sprint Review. Inspect the usable Increments with relevant stakeholders and review available outcome/experiment evidence. Decide how the product/service, backlog, or approach should adapt. Outcome evidence may still be pending; retain its source, owner, and observation date. Do not infer impact from delivered work.
- Sprint Retrospective. Inspect effectiveness, quality, coordination, and working conditions. Check the last improvement and choose one useful next improvement. Keep facts separate from explanations and avoid blame.
- Next Sprint Planning. Use the Review's delivery/outcome decisions and Retrospective's improvement to select the next coherent goal and feasible work. If there is no previous sprint, begin with Planning after checking starting evidence.
Previous Sprint Review → Sprint Retrospective → next Sprint Planning is the boundary sequence. MktOS's compact weekly routine combines review/inspection and retrospective purposes in one session, then plans. These remain distinct purposes even when no extra meeting is scheduled. Monthly or quarterly review decisions can feed the same boundary.
An experiment can span several sprints. Closing delivery does not erase observation work: retain owned follow-up and its date. If waiting is inside the Definition of Workflow's start/finish boundary, include it in WIP and elapsed time. Define separate linked delivery/observation flows where appropriate rather than hiding waiting.
Sources and adaptation
- The Scrum Guide, Ken Schwaber and Jeff Sutherland, November 2020: Sprint and formal event names, inspection/adaptation, artifact commitments, usable Increments, and ongoing refinement. MktOS adapts these to marketing, solo work, and combined sessions.
- GitLab Handbook: Cadence: practitioner example distinguishing the period a plan concerns from its update frequency and connecting longer-term direction with shorter cycles. The MktOS cycle table is an integration choice, not GitLab's prescribed calendar.
The source inventory retains broader references and unresolved attribution. This page does not import another methodology's full meeting system. Record actual time, decisions, and friction when the configuration is used; documentation completeness is not evidence of independent usability.