Status: documented, untested. Part of the MktOS Guide. An artifact makes work, value or reasoning available for inspection. It can be a shared document, board view or usable output; it does not require a separate file.
Use established source names for the integrated artifacts. The entity-relationship model distinguishes outcomes, work, collections, outputs and rules. Its cardinalities are proposals for MktOS, not universal framework requirements.
Preserve the planning structure
MktOS already uses North Star → Objectives and Key Results → Projects → Milestones → Tasks. The artifacts below organize and support that structure; they do not replace it.
| Existing element | Place in the integrated system |
|---|---|
| North Star Metric | Enduring customer-value measure for a defined scope, recorded in the marketing plan. A period revenue target is not automatically a North Star Metric. |
| Objectives and Key Results | Desired improvements and their measurable evidence, recorded in the plan and linked from the backlog. |
| Projects | Bounded interventions supporting KRs; represented in the Product Backlog. |
| Milestones | Meaningful project checkpoints; represented within their projects. |
| Tasks | Actionable work advancing milestones; selected into the Sprint Backlog when ready. |
A project can influence several KRs. Link the expected contribution rather than forcing every relationship into a strict tree. Completion criteria apply to work; a sprint groups selected work in time. Neither adds another hierarchy level.
Integrated artifacts
All eight selected artifacts are part of MktOS. Their use follows the decision or work involved: maintain delivery artifacts as work proceeds; revisit the Canvas when business-model assumptions matter; use an A3 for a problem-solving initiative and paired Test/Learning Cards for experiments. Reuse an existing valid artifact and link it instead of recreating it for every task.
| Artifact | Purpose | Minimum contents in MktOS |
|---|---|---|
| Product Backlog | Order the work needed to improve a defined product or service and advance related marketing outcomes. | Product/service scope and Product Goal; ordered backlog items linked to projects, milestones/tasks and objectives/KRs as relevant; expected contribution; owner and status. Before selecting work: sufficient scope, size, dependencies and acceptance criteria. |
| Sprint Backlog | Make the next delivery commitment and approach visible. | Sprint Goal; selected backlog items; actionable tasks; contributor capacity and dependencies; current progress and adjustments. A filtered view of the same backlog can implement this if it also exposes the goal and delivery approach. |
| Increment | Provide a usable, verified addition to the defined product or service. | The actual usable output; link to the work and intended goal; evidence it meets the Definition of Done, works with previous increments, and meets item acceptance criteria. A tracking implementation, published page or research conclusion can qualify when it is usable in that scope; a task status or unfinished draft alone does not. |
| Definition of Workflow and board | Explain how work enters, moves through and finishes delivery. | Work-item types; start/finish boundaries; states; work-in-progress controls; movement/blocker/urgent-work policies; service-level expectation with elapsed time and probability, labeled provisional until supported by history. The board visualizes these agreements. |
| A3 report / storyboard | Make the reasoning for a problem and its proposed response inspectable. | Problem and current evidence; desired condition; analysis; possible responses and chosen approach; owner/action plan; results and follow-up. Keep it a living concise problem-solving story. |
| Business Model Canvas | Examine how the business or offering creates, delivers and captures value. | Customer segments, value propositions, channels, customer relationships, revenue streams, key resources, key activities, key partnerships and cost structure; model scope/date and explicit assumptions. |
| Test Card | Specify how an important assumption will be tested before execution. | Hypothesis; test/intervention; metric; decision threshold. Add an owner, data source and observation window so the test can actually be run and assessed. |
| Learning Card | Turn observations into an explicit decision. | Question and hypothesis/Test Card link where relevant; observed evidence; interpretation and limitations; resulting decision/action. Name the action owner and next review if observation continues. MktOS also permits research/performance learning without a formal experiment; this broadens the source tool's experiment-focused use. |
Commitments and quality
Following Scrum's artifact/commitment relationship, MktOS adapts:
- Product Backlog → Product Goal: the future state of its defined product or service guiding work selection. Align with objectives and KRs; reuse a compatible objective statement when it expresses that future state. Do not equate every objective, revenue target or North Star Metric with a Product Goal. Work toward one Product Goal at a time per Product Backlog; retain previous goals as history.
- Sprint Backlog → Sprint Goal: the useful objective that gives selected work coherence. Tasks can change as understanding improves; a threatened or obsolete goal requires an explicit decision.
- Increment → Definition of Done: the shared quality standard for usable output. State applicable checks before delivery: intended use supported, work verified, necessary review completed, and evidence/output accessible. Item-specific acceptance criteria add the checks particular to that deliverable.
These commitments belong with their artifacts. They are not three additional documents. The Definition of Done establishes output quality; a project's done-when gate establishes its declared completion conditions; KRs establish outcome achievement. Keep those judgments separate.
How the artifacts connect
- Use the Canvas to expose relevant business-model assumptions and A3 to investigate the priority problem. Link existing research rather than repeating it.
- Record strategic choices, North Star and OKRs in the marketing plan. Strategy remains a choice about how to create value, not just a list of targets.
- Order the supporting projects, milestones and tasks in the Product Backlog. Agree the Definition of Workflow and visualize that same work.
- Create a Test Card for an experiment before selecting its execution work. In G.R.O.W.S., this supports Outline; the Learning Card supports Study.
- Select ready work into the Sprint Backlog. Produce usable Increments meeting the Definition of Done.
- Inspect delivery and results through the weekly routine. Complete or update the Learning Card and A3 with actual evidence, then adapt the plan and backlog.
This is a connected loop, not a requirement to finish every document before delivering value. Keep each fact in one place. A3 can be the project's problem/decision section; cards can be sections of the same experiment; backlog and board are views of the same work. The Canvas describes the business model and does not replace the marketing strategy.
An experiment may need several sprints of observation. Waiting does not consume an active delivery slot, but still belongs on the board or in an explicitly linked follow-up record. If the defined start-to-finish boundary includes that waiting period, it counts as WIP and elapsed time; alternatively define delivery and observation as separate linked flows. Never hide waiting to improve flow metrics.
Templates, credit and adaptations
Use the existing marketing plan with the artifact prompts. These are MktOS working prompts, not reproductions of official branded templates.
- Scrum artifacts and commitments: Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020. Retain the source names. Their application to marketing and the links to OKRs/projects are MktOS integration choices; this does not constitute full Scrum adoption.
- Workflow definition: The Kanban Guide, May 2025. MktOS combines flow visibility with sprint planning; a board alone does not establish adoption of all Kanban practices.
- A3: Toyota-origin practice described by the Lean Enterprise Institute. MktOS applies its reasoning structure to marketing problems; filling a template is not the entire A3 management practice.
- Business Model Canvas: Strategyzer's official tool. Retain its nine connected blocks and treat entries as claims to examine.
- Test Card: Alex Osterwalder, Strategyzer, 5 March 2015.
- Learning Card: Strategyzer, explained by Nabila Amarsy, 9 March 2015. MktOS adds ownership, timing and links to the existing planning hierarchy.
Source provenance and remaining gaps are maintained in the source register.