Agile and Scrum
Agile is an approach to developing useful software through collaboration, frequent feedback, and adaptation. Scrum is a specific framework for organizing work on complex problems. They are related, but “Agile” is broader than Scrum, and a team does not become adaptive merely by renaming its meetings.
The practical question is how a team can learn early enough to change course while remaining accountable for what it delivers.
In this toolkit, scrum-skill supports that delivery work. It connects the process architecture produced by legal-processmodelling-meta-skill with capabilities such as sg-legalresearch-skill. The connection is developed below, after the foundations.
Why deliver in increments?
Requirements are often incomplete at the start. A lawyer may ask for an “automated review tool,” but a prototype can reveal that document version identification and clear escalation criteria matter more than another drafting feature.
Delivering a small, usable improvement gives people something concrete to inspect. The team can test its assumptions before building the entire system around them. Planning still matters; the plan is revised when evidence warrants it.
View the relationship model
flowchart TB
G["Agree a valuable outcome"] --> B["Choose a small increment"]
B --> D["Design, build, and verify"]
D --> U["Inspect a usable result"]
U --> L["Learn with users"]
L -->|Adapt the next choice| BThe Agile values (2001) emphasise people, usable software, collaboration, and responsiveness to change. This does not remove the need for documentation, contracts, or plans. Those artifacts should help the team deliver and understand the work.
What Scrum specifies
The 2020 Scrum Guide defines three accountabilities within a Scrum Team:
| Accountability | Contribution |
|---|---|
| Product Owner | Maximizes product value and is accountable for effective Product Backlog management |
| Developers | Create a usable Increment and adapt their plan toward the Sprint Goal |
| Scrum Master | Establishes Scrum and helps the team and organization use it effectively |
“Developers” describes people doing the work of creating the Increment. It is not limited to people writing code. Equally, an AI assistant does not become the accountable Product Owner or Scrum Master because it can generate a backlog or meeting agenda.
Scrum works through transparency, inspection, and adaptation. Its five events are the Sprint, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. The Sprint is the container for the other events and lasts one month or less.
View the relationship model (Mermaid)
flowchart TB
P["Product Backlog<br/>Commitment: Product Goal"] --> PL["Sprint Planning"]
subgraph S["SPRINT: ONE MONTH OR LESS"]
PL --> B["Sprint Backlog<br/>Commitment: Sprint Goal"]
B --> W["Create and verify an Increment"]
W --> DS["Daily Scrum<br/>Inspect progress and adapt the plan"]
DS --> W
W --> I["Increment<br/>Commitment: Definition of Done"]
I --> R["Sprint Review<br/>Inspect the outcome with stakeholders"]
R --> RT["Sprint Retrospective<br/>Improve how the team works"]
end
R -->|Adapt product direction| P
RT -->|Improve the next Sprint| PLThis diagram emphasizes the feedback loops. It is not a requirement to wait until the Sprint Review to release value. A usable Increment may be delivered earlier; a review meeting is not a release approval gate.
Make work testable
A user story connects a role, a desired capability, and a purpose. For example, a supervising lawyer requires an exception summary linked to the relevant clauses so that departures can be reviewed without reconstructing the comparison.
Acceptance criteria might require each reported departure to include a clause location, the relevant playbook criterion, and an explicit indication when no reliable match is found. These criteria help people discuss scope and design tests.
Acceptance criteria for one item differ from the Definition of Done, the quality standard applied to the Increment. A team may require review, tests, documentation updates, and resolution of specified defects before work is Done. Neither device establishes that every future legal conclusion will be correct.
Estimation supports a conversation
Scrum does not prescribe story points, velocity, or planning poker. Teams may use them to discuss effort, uncertainty, and capacity. Points are not hours, and velocity is not a sound way to rank different teams or individuals.
AI can make drafting or coding faster while moving the bottleneck to review. Estimates and planning should reflect the whole path to a usable result, including verification, integration, and correction.
An example across the three layers
The toolkit pins seven components across three layers. This research handoff illustrates three of them: process design, delivery coordination and a bounded research method. It does not use every component in every workflow.
| Component | Job in the toolkit | Example contribution |
|---|---|---|
legal-processmodelling-meta-skill | Models the current and proposed process, generates reusable skills, and manages workflow state | A research request must pass scope approval before research begins, then return for lawyer review |
scrum-skill | Helps people plan, coordinate, inspect, and improve the implementation | A backlog item requires a tested research handoff with explicit inputs, source evidence, and a rejection path |
sg-legalresearch-skill | Supplies a reusable Singapore legal research method for the active host | Research the accepted question using available sources, recording authorities, source locations, and coverage limits |
These are components of a proposed legal engineering framework. Their value lies in making responsibilities and interfaces inspectable; installing the skills does not by itself establish professional competence.
Build the service, then operate it
Consider a litigation team introducing a structured research service. The process meta-skill first helps the team agree the scope, decision authority, and handoffs. The implementation team uses scrum-skill to turn that design into deliverable increments: validate intake, bind the research method, test missing source access, and verify the lawyer's review step.
One Sprint Goal might be: “Enable a scoped research request to reach lawyer review with an evidence record.” The team can inspect a working handoff and adapt the backlog. A usable Increment also needs the team's Definition of Done; a successful demonstration alone is insufficient.
Once the service runs, the process runner makes the research task eligible. The active host follows sg-legalresearch-skill with the matter's inputs and connected tools, then submits a structured result for validation and lawyer review. That request does not need to pass through a Sprint ceremony. The delivery team can subsequently use defects and feedback to improve the service, subject to the workflow's change and approval requirements.
The three-layer architecture explains these interfaces, delivery and coordination develops the implementation approach, and the synthetic research handoff follows a request through the workflow. The example demonstrates routing with fixtures; it does not establish the accuracy of live legal research.