Why Scrum
When small teams move from "let's get things done" to "let's get things done together with a rhythm," sooner or later they meet Scrum. And almost always they drop it after two weeks: too many rituals, too many tools, too much jargon.
We wanted to try a different path. Keep the value of Scrum — a short horizon, explicit decisions about what to do, an honest retrospective — and throw the rest away.
What we built
Four phases, four releases, one idea: give the scrum team the bare minimum, done well.
Sprint
The sprint is the container. It has a name, a goal, a start date and an end date. Three states: PLANNED, ACTIVE, CLOSED. Create it in one click, start it when you're ready, close it when you're done. You can also close it before the end date if you decide it's time — with an explicit confirmation, because we don't like accidental cancellations.
No extra fields you'll never use. Only what's needed to answer the question "what are we doing this week?".
Product Backlog
The backlog is the list of tasks not yet assigned to a sprint. Same project view, same task model — nothing new to learn. Filtering and ordering by priority, story points, assignee. Multi-select to bulk-move tasks to a specific sprint, or send them back to the backlog if the plan changes.
No "epics," no forced "user stories." A task is a task. It has a title, a description, an assignment, an estimate, a priority. That's it.
Sprint Board
The sprint kanban board. Columns come from the project's Project Task Status entries — fully customizable: "To Do / In Progress / Done" for the classics, or richer flows ("Ready / Doing / Review / Done") for more articulated pipelines.
Drag & drop between columns. The state of a card on the board is separate from the task's global status: when you move a card from "In Progress" to "Review," you're not marking the task as completed — you're saying "I'm done writing it, now I'm waiting for the review." Only the "completed" toggle (or pushing progress to 100%) actually marks the task as done. And the system keeps is_completed, progress and the global task status always coherent, automatically.
Story Points and capacity
Every task can have story points. You assign them from the backlog row, from the card on the board, or from the task detail drawer. No magic velocity formulas calculated on nothing — points are an estimation tool for the team, not a metric for managers.
When you close a sprint, uncompleted tasks can be automatically sent back to the backlog or moved to the next sprint. The choice is yours, your retrospective's, your common sense's.
What we left out (for now)
- GitLab-style velocity dashboards: we prefer the team to look at what they did this week, not a decontextualized historical chart.
- Integrated backlog estimation poker: too many general-purpose tools already exist, and frankly poker over a call works perfectly fine.
- Structured ceremonies notes (planning / review / retrospective): coming in the next phase. For now there are free-text fields on the sprint for goal, planning notes, review notes, retrospective notes.
We built what we use ourselves, and what we see the teams we work with using. No placebo features "to fill out the pricing page."
Who it's for
For small teams working in iterations (weekly or biweekly) who want a tool that doesn't slow them down. For founders who need to see at a glance what's happening this week. For consultants and freelancers managing multiple projects who want to group them into short cycles.
If you live Scrum as a dogma and want the full liturgy (epics, "As a... I want..." story format), Jira does it better. But if you think practice beats theory, try ProWoDo.
Next on the roadmap
- Ceremonies notes UI: dedicated blocks for planning, review and retrospective — not a free-text field but a lightweight structure that supports the ritual without weighing it down.
- MCP tools for sprints: today tasks are accessible via MCP, sprints aren't. We're working to expose them — so you can ask Claude "which sprints do we have open this month?" and get the right answer.
- Real velocity: only after a few real sprints have closed, to avoid bogus numbers.
ProWoDo is in beta, we build it iteratively, and every feature starts from a concrete problem we (or one of our users) have lived through. Scrum is no exception.
If you try it, tell us how it goes.