Scrum is dead?

Most of what Scrum gives a team was designed around one fact: building was the expensive part. A sprint of engineering time was the scarcest thing you had, and getting the work wrong cost you a whole sprint. You didn't get many chances, so you spent a lot of effort reducing the uncertainty before and around the work. Refinement sessions, estimation, acceptance criteria written up front, a board someone kept tidy so everyone knew what was in flight.

Building is no longer the expensive part. With agents doing most of the typing, we don't need to be sure before we start; a rough idea of what we want will do. We can try the idea, look at it running, test more of it than we used to, and throw the code away without it being the end of the world. A spike that used to cost a week now costs an afternoon, and the cheapest way to settle an argument about how something should look is often just to build both versions.

When being wrong costs an afternoon, you get many chances instead of one. That changes what the ceremony around the work is for. It doesn't remove the need to know what's going on. It moves it.

Tickets are now memory and release notes

Tickets now work more as memory for AI agents and as release notes than as a way to track work.

Think about who actually reads a ticket today. An agent picking up a piece of work reads it to understand the problem, why it matters and what's out of scope, because it can't lean over and ask the person who wrote it. And whoever looks back later reads it to understand what shipped and why. The person who reads it least is the one dragging it across a board, because the board is usually already out of date.

That memory has to live somewhere, and the repository is the wrong place. It's tempting to keep specs, plans and to-do files next to the code so the agent can find them. But the code is the only source of truth, and every spec in the repository is a second one that starts going stale the day it's merged. An agent can't tell which one is right, so it either follows the outdated plan or spends tokens reconciling the two. It's the same problem as a comment that no longer matches the code under it, which we had long before agents; agents just read everything, so they trip on it more often. Keep the repository to code, and keep the intent, the open questions and the history in the task, where an agent reads it when it picks up the work and nobody has to keep it in sync.

Clocktopus v1.15 introduces tasks, built around that. We're not trying to compete with Jira or Linear. You can integrate with them, and tickets from either arrive as tasks with their key, title, description and link. But we expect you'll need them less and less as a tracker.

Tasks in Clocktopus can only be created through an integration or by an agent. In the app, the only thing you can do is cancel a task to move it out of the way. You never move tasks yourself. Git commits and agents do that for you:

• a branch, commit or agent session that names the task's key starts it;
• a pull request ready for review puts it in review;
• merging that pull request makes it ready to ship;
• once the work reaches the project's delivery branch, the task is marked as delivered.

There's no "remember to update the ticket" step, because there's no ticket to update. If a task says it's in review, a pull request for it is open. If it says delivered, the code is on the branch you ship from.

Goals, not chats

Tasks come with a set of agent skills that guide your agents on how to handle individual tasks or goals. A goal is a group of tasks that need to be completed to reach a larger milestone, like "customers can export invoices". It has an order to work its tasks in, and it's reached once every one of them is delivered.

This changed how we work. We stopped chatting with agents and started focusing on outcomes.

Chatting with an agent feels productive, but most of it is steering: answering the same questions, re-explaining context, nudging it back on course. The skills move that work to the start, where it's cheaper.

Ask your agent to /create-goal and describe what you want to achieve. The skill checks your existing tasks for anything relevant and creates the ones that are missing, in the order they need to happen. Once that's settled, you can /refine a single task or the whole goal. Refining reads the code the task touches and asks you its open questions in one round: which page, which edge cases, what's deliberately left out. The answers go into the task, so it's ready for an agent to carry to a pull request without asking. Refining up front cuts down the questions an agent has while building, so you spend less time babysitting it.

Then /start-work takes the goal's next task, or one you name, onto a branch carrying its key and through to an open pull request. Its commits, pull request and agent spend all count towards that task from the first minute.

Use /create-task when you just want to capture something important. Agents often suggest these: things that matter but aren't the focus right now, and that would pull you away from what you set out to do if you chased them there and then. A flaky test spotted on the way past, a warning worth fixing one day, a follow-up the current change uncovered. Capture it as a task and you stay focused on the goal, and a later refinement can pull the task in without long backlog sessions with your team.

Small tasks, reviewable pull requests

Breaking a goal into small tasks isn't only for the agent. It's for whoever has to review the result. One of the biggest problems developers have right now is the size of the pull requests agents write. Give an agent a vague, goal-sized request and it comes back with a two-thousand-line pull request that touches everything, and nobody can review that properly. It either sits for days or gets waved through.

A goal fixes that by shape. Each task is small enough to be one focused pull request, and when you work through a goal, each one is stacked on the one before it in git: the second task's branch builds on the first, the third on the second. Your team reviews them in order, from the bottom of the stack up, one small change at a time, and each can merge as soon as it's approved instead of waiting for the whole goal. The agent keeps moving through the goal while the reviews catch up behind it.

Let goals run overnight

Some goals take a while to finish, and that's fine. Because every task is refined up front, an agent working through a goal doesn't need you sitting next to it. So run it when it won't eat into your quota: hand the goal to an agent at the end of the day, let it work through the tasks overnight, and come back the next morning to a stack of pull requests ready for review and a fresh quota to start the day with.

A board that moves itself

The tasks board updates automatically, and you can see which agent is working on what. It also links agent and human costs, which has always been our goal: being able to say how much a task costs. Open a task and you see the hours people put in, what the agents spent, and the two together.

If your team works through Slack or other messaging tools, this is for you too. Agents file tasks, your team delegates tasks to agents, and the board gives you full visibility of what's going on, including the PRs you need to review. No more switching between dashboards to work out what's next. The Clocktopus Work tab always has the latest snapshot.

The same goes for wherever you drive your agents from. Git moves a task along whichever editor or front end the work came from, and any agent or AI assistant that can reach the Clocktopus MCP server, Claude.ai and ChatGPT included, can manage tasks and goals.

Metrics from idea to delivery

This is an opinionated way to deliver, but tasks were also crucial for giving you accurate metrics from conception to delivery.

Because a task's stages come from git rather than from someone remembering to click, the timestamps are real. Clocktopus knows when a task was created, when the first commit for it landed, when its pull request merged and when the work reached the delivery branch. From that it can give you change lead time (first commit to shipped), how long tasks take from being created to shipping, and how often you ship at all.

Your personal or team dashboard shows where the bottleneck is, so you can see what's slowing you down. When building gets cheap, the bottleneck doesn't disappear, it moves. When we turned it on for ourselves, pull requests were merging within the hour, and the pile-up was further down the line, in "ready to ship": work that was merged and done, waiting for a release. Most of the tasks we'd created that week were sitting there. No retrospective would have found that, because from inside a sprint it feels like the work is finished.

So, is Scrum dead? The parts that existed to protect expensive engineering time are fading, because that time isn't the constraint any more. What's left is the part that always mattered: knowing what you're trying to achieve, and seeing honestly how the work is getting there. That's the part we built tasks for.

One command to set it up

You don't need to configure any of this by hand. Install the CLI and run init inside a checkout of your repository:

npm install -g @blastin-dev/clocktopus-cli && clocktopus init

It signs you in, finds or creates your organisation and project, connects the repository (through the GitHub App, or a webhook), checks your git email is the one Clocktopus tracks, and sets up your coding agents with the skills above. It only says it's done once a real commit has arrived, so you know the whole chain works before you rely on it. The CLI docs go through each step.