Scrum4Me

From idea to verified pull request.

Scrum4Me is a Scrum workspace where AI agents do the building and you keep the say. An idea is challenged, planned, put in a sprint, built by agents and checked before it reaches your repository.

Try the demoRegister

Demo login: username demo · password demo1234

Beta · desktop-first (1024px+) · accounts and data may be reset during this phase.

Product backlog in Scrum4Me with PBIs, stories and tasks side by side

Scrum4Me is built with Scrum4Me

sprints closed
145
tasks done
1,788
agent jobs completed
805
pull requests merged
316
product docs
315

These numbers come from the backlog and repository of Scrum4Me itself. As of: October 4, 2026.

One pipeline, five visible steps

Every step leaves something you can open and read: an idea, a plan, a sprint, a job log, a pull request.

  1. 1

    Idea

    Write down what you want in a paragraph. The idea gets a code and a status and becomes the first traceable input.

    Ideas list with ideas in every stage, from draft to planned
  2. 2

    Grill + Plan

    An agent questions the idea until the gaps are closed, then writes a plan. A second model reviews that plan before anything is built.

    Idea detail on the Plan tab, showing the plan an agent wrote
  3. 3

    Sprint

    An approved plan becomes one PBI with stories and tasks, placed in a sprint with a goal. Nothing runs until you start it.

    Sprint screen with product backlog, sprint backlog and the tasks of a story
  4. 4

    Agent run

    A worker claims the job, works in an isolated copy of your repository and reports each step, test and commit back.

    Jobs screen with active jobs on the left and finished jobs on the right
  5. 5

    Verified result

    The work arrives as a pull request with its plan, test results and commits attached. Insights shows what was delivered and what it cost.

    Insights with sprint health, burndown and agent throughput

You stay in control

Agents ask before they act. Permission requests and questions reach your iPhone and Apple Watch, so a run does not wait until you are back at your desk.

  • Approve from your wrist

    Allow or deny a request straight from the notification on your Watch or iPhone.

  • Rules instead of repeated questions

    Turn a recurring approval into a shared permission rule, for one product or for everything.

  • Questions wait for you

    When an agent needs a decision it asks, and continues as soon as you answer.

iPhone app with an open approval request and the buttons Allow and Deny
iPhone app showing one request with room for an explanation
iPhone app with the list of agent tasks
Apple Watch notification with the buttons Allow, Deny and Open on iPhone
Apple Watch showing a queue message
Hub page with paired devices and shared permission rules

Within your standards

Agents work from what you have written down, not from guesses.

Documentation overview with folders for ADRs, architecture, patterns, plans and runbooks

Product docs with revisions

Architecture, patterns and runbooks live with the product. Agents search them before they build, and every change keeps its earlier versions.

A product doc viewed in an earlier version, with the version list beside it

Definition of Done

Each product carries its own Definition of Done, and work is checked against its plan before it counts as done.

Product settings with agent, auto-review and plan review options

Agent settings per product

Decide per product whether pull requests open and merge automatically, which reviews run and how a sprint delivers its work.

Around the sprint

Issues list with code, severity and status

Issues

Problems per product or system, with severity, research notes and resolution.

Notes list with keyword filters

Notes

Snippets and working context you want to keep, searchable by keyword.

Insights with agent throughput, velocity and backlog health

Insights

Sprint health, agent throughput, token use and backlog health.

How it is built

Planning app, worker console, tool server and runner are separate parts around one Postgres database. Code stays in your own git environment.

Scrum4Me platform: Scrum4Me web, scrum4me-workers, Neon Postgres, scrum4me-mcp, scrum4me-docker, Claude Code, Forgejo and scrum4me-shared.
  • Next.js 16, React 19, TypeScript and Tailwind CSS v4
  • PostgreSQL with Prisma; realtime through LISTEN/NOTIFY and SSE
  • MCP server and Docker runner for Claude Code; SwiftUI for iPhone and Watch

Documentation

Reference material for working with Scrum4Me yourself. Open what you need.

Quickstart - runner or local MCP development

The normal route uses the headless Docker runner. For local tool development you can connect the MCP server directly to Claude Code.

Path A - normal runner

  1. Create an implementation token in scrum4me-workers.jp-visser.nl/api-tokens.
  2. Put the token, Claude OAuth token and git credentials in the runner env.
  3. Start scrum4me-docker on a NAS, server or laptop.
  4. Check the heartbeat in scrum4me-workers.jp-visser.nl/workers.
  5. Click "Execute" in Scrum4Me.

Path B - local MCP development

git clone https://git.jp-visser.nl/janpeter/scrum4me-mcp.git
cd scrum4me-mcp && npm install

# Add it to the Claude Code config
# and use the Scrum4Me MCP tools directly.

Useful for tool development, product-doc retrieval and local inspection. The production runner remains the recommended route for real job execution.

Prefer to skip MCP? Use the REST API with a Bearer token for scripts, CI pipelines and controlled integrations.

Where do you manage what?

Change product, backlog, sprint or ideaScrum4Me
View product docs, grill and plan documentsScrum4Me
Inspect job queue or cancel/restart a jobscrum4me-workers
See worker online/offline statusscrum4me-workers
Create or revoke an API tokenscrum4me-workers.jp-visser.nl/api-tokens
Start runner on NAS/serverscrum4me-docker
Change MCP toolsscrum4me-mcp
Change schema/status/job configscrum4me-shared first, then consumer bumps
Scrum in Scrum4Me

Scrum4Me applies a lightweight version of Scrum: the essentials without ceremony overhead. This is how the core terms map to the app.

Hierarchy

Idea
DRAFT - GRILLED - PLAN_READY
↓ materializes to
Product
A software project or codebase
PBI
Product Backlog Item, a feature or improvement
Story
Concrete user story inside a PBI
Task
Implementation step inside a story

Terminology

Idea
A proposal or direction before it becomes a PBI. It has a grill phase, where Claude challenges it, and a plan phase, where Claude writes YAML with stories and tasks.
Grill / Plan
Two asynchronous Claude job types for an idea. Grill produces grill_md. Plan produces plan_md, a strictly parsed YAML plan with PBI, stories and task templates.
Product Backlog
Ordered list of all PBIs per product, sorted by priority and position.
Sprint
Active timebox with a Sprint Goal. A product has at most one active Sprint at the same time.
Sprint Backlog
Stories selected for the Sprint. Stories are dragged from the Product Backlog.
Sprint Board
Three-panel screen in one view: Product Backlog, Sprint Backlog and tasks for the selected story.
Solo Panel
Personal Kanban board per product. Shows tasks from claimed stories in To Do, In Progress and Done columns.
Story claim
A developer claims a story from the Sprint and becomes assignee. Pull system, not pushed by a Scrum Master.
Story status
OPEN -> IN_SPRINT -> DONE. Controls visibility in backlog and Sprint screens.
Task status
TO_DO -> IN_PROGRESS -> DONE. Updated through the UI or REST API by Claude Code.
Activity log
Implementation plan, test result and commit are stored per story through API or UI.
Close Sprint
At Sprint close, each story is marked done or moved back to the Product Backlog.

Roles

Product Owner
Prioritizes PBIs and manages the Product Backlog.
Scrum Master
Guards the Scrum process and removes obstacles.
Developer
Executes stories and tasks through the UI or Claude Code.

In v1, one account equals one user with all roles. Team usage with role separation follows in v2.

User guide

Follow these steps to go from an empty account to a fully planned Sprint.

1
Create an account
Go to Register and choose a username and password. After registration you are sent to the dashboard. Prefer passwordless? Pair your phone once and log in by QR. Or try the demo account first.
2
Create a product
Click "New product" on the dashboard. Enter name, optional description, repo URL and your Definition of Done. The product appears on the dashboard.
3
Capture an ideaIdea route
Open /ideas, click "New idea" and enter a title plus a one-paragraph description. Status: DRAFT.
4
Let Claude grill itIdea route
Click "Grill me". A local agent asks critical questions through the notification icon. Answer them; Claude writes structured grill_md. Status: GRILLED.
5
Make the plan and materializeIdea route
Click "Make plan". Claude generates a YAML plan (PBI + stories + tasks). Click "Materialize" to atomically turn it into product backlog work. Status: PLANNED.
6
Fine-tune the Product Backlog
Optionally reorder PBIs and stories manually with drag-and-drop. Most work has already been materialized; this is for steering or adding work that did not come from an idea.
7
Start a Sprint
Click "Start Sprint" on the product page and enter a Sprint Goal. A product has at most one active Sprint at the same time. The Sprint screen appears in navigation.
8
Sprint Board - drag stories and create tasks
Open the Sprint screen. Three panels appear in one view: Product Backlog left, Sprint Backlog middle, tasks right. Drag stories into the Sprint Backlog and select a story to see tasks.
9
Solo Panel - claim stories and work personally
Open Solo from navigation. Claim open stories from the active Sprint and move tasks through three status columns. Click a task for detail and implementation plan.
10
Connect worker runtime
Create an implementation token in scrum4me-workers.jp-visser.nl/api-tokens and put it in the runner env. The workers app manages jobs, workers, tokens and repo access; Scrum4Me remains the planning UI.
11
Execute and follow the Sync tab
Click "Execute" on a story in the Solo Panel. A ClaudeJob is created; scrum4me-docker claims through MCP, works in a worktree and writes status/logs back. Follow progress in the Sync tab and scrum4me-workers.jp-visser.nl/jobs.
12
Close the Sprint
Click "Close Sprint" on the Sprint Board. For each story, choose done or move back to Product Backlog. After that, a new Sprint can be created.
REST API for controlled integrations

All API endpoints require an Authorization: Bearer <token> header. You manage implementation tokens in scrum4me-workers.jp-visser.nl/api-tokens.

# Fetch the next story from the active Sprint
              curl -H "Authorization: Bearer $TOKEN" \
              https://<your-instance>/api/products/<product-id>/next-story
GET/api/productsList active products
GET/api/products/:id/next-storyHighest-priority open story from the active Sprint
GET/api/sprints/:id/tasks?limit=10First N Sprint tasks in order
PATCH/api/stories/:id/tasks/reorderChange task order (body: { task_ids: string[] })
POST/api/stories/:id/logRecord activity: implementation plan, test result or commit
PATCH/api/tasks/:idUpdate task status or implementation plan