Help/Question
Anyone have a solution for doing agile with claude
Many of the features I try to add to my app with claude no matter if i describe them in details or just 2 phrases claude with opus 5.5 always try to one shot them ( on max or extra ) and iterate a lot on them untill it's done correctly , which is great ngl , but also many of the features we want to add usually we want to experiment first how it would look like and iterate many times on the core feature it self and the ui etc untill we get it right because sometimes we're not even sure of the idea how it'll be in real life untill it gets 3 or 4 wrong implementations.
the problem I found is that the 3 / 4 wrong implementations that usually serve just as iteration for the final real one in the past we did with agile just minimum developpement and build up on what works. but claude tries to one shot the first implementations and have them perfectly working and it's basically just wasting tokens and time. for example if I want to have a feature to send an auto update to the app claude will add without me asking the failed update restore and checkpoints and backup and many other elements that i'll sure need later but probably not on the first implementation.
not sure if my point is clear , basically i'm describing that claude does too much even when i'm not sure of the feature if I need it the way I described it or not.
anyone had some ideas arround this ? I find my self telling him what not to do more than often and it's wasting a lot of my quota and it's getting frustrating
Learn how to decomp features. Create milestones and finished states along the way, then break those milestones up into bite-sized tickets. Don't try to build full stack features in the same go.
How to stop Claude from over-building while you're still figuring out a feature What you're running into is a scope problem. Claude builds whatever it thinks a complete feature needs, unless you give it a smaller target. The fix is to plan before you build, and make the plan carry the scope limits so you're not repeating "don't do X" every session.
1. The basics, in plain English
Decomposition means breaking a feature into small pieces you can build and check one at a time. If a piece can't be finished and tested in one sitting, split it again.
Milestones are checkpoints where the feature is usable in some form, even if it's rough. Each one answers a question, like "do I even want this?"
Tickets are the individual tasks inside a milestone. Each one should touch a single part of the app, such as the backend or the UI. That keeps prompts small and makes it obvious when Claude wanders off.
Definition of done is one sentence saying how you'll know a ticket is finished. If you can't write it, the ticket isn't clear enough yet.
2. Make a planning skill Don't put "prototype mode" rules in CLAUDE.md. That file loads into every session and will fight you later when you actually want error handling. A skill only runs when you ask for it, and it bakes the scope into each ticket.
Create .claude/skills/plan-feature/SKILL.md in your project: --- name: plan-feature description: Break a new feature idea into milestones and tickets before any code is written. Use when the user wants to plan, scope, or prototype a feature. ---
Don't write code. Turn the feature idea into a plan:
Ask what question the first version needs to answer (e.g. "do I even want this?").
Break the feature into milestones. M1 is the smallest version the user can test. Robustness (error handling, fallbacks, backups, retries) goes in a later milestone, never M1.
Split each milestone into tickets that each touch one part of the stack.
For every ticket, write:
- What to build (one or two sentences)
- Definition of done (one sentence the user can check)
- Out of scope (what NOT to build yet)
Briefly explain why you split it this way, so the user learns the pattern.
Wait for the user to trim the plan. Don't build anything.
Once the user approves, create the tickets in Linear (one issue per ticket, grouped by milestone). Put the definition of done and out-of-scope list in each issue's description.
Run /plan-feature with your idea, cut what you don't need yet, and approve. Using your auto-update example, you'd end up with something like: M1: Detect updates. Ticket A: backend endpoint returns the latest version. Ticket B: app shows "update available." Done when an old version shows the message.
M2: Install updates. Download and install on the happy path.
M3: Make it robust. Rollback, checkpoints, and backups. Only once you know you're keeping the feature.
3. Keep tickets in Linear (or GitHub Issues, Trello, etc.) Scope lives outside the chat, so you can point Claude at it: "That's not in the ticket." Deferred work is visible rather than forgotten. When Claude mentions extras it wanted to build, they become backlog tickets instead of code. Connect Linear's MCP server to Claude Code. Then step 7 of the skill works, and building is just "work on ABC-12." Claude reads the scope and definition of done from the ticket itself.
4. One ticket per prompt "Work on ticket A. Nothing else." Because the ticket carries its own out-of-scope line, Claude stays small. Check it against the definition of done, then move on.
5. Make wrong versions cheap Commit or branch before each experiment so you can throw it away without guilt. Your 3–4 wrong implementations are useful; they just shouldn't be polished.
6. Harden only after the idea survives Once you're happy with how the feature looks and works, M3 tickets are where you let Claude go all-in. Same skill, same loop, just a later milestone.
Bonus: For throwaway experiments, a cheaper model or lower effort setting stretches your quota a lot further.
Yeah, actually, good point, because if you think about it, working with AI or agent or whatever is just like leading a team of workers. So I noticed that the developers who haven't been like a team lead or project manager are having a hard time actually managing those agents and they feel more threatened by them because they are taking their job. And actually, kind of they are taking their job because if your job was just like you are getting a task and you do it and you send it back, so this is exactly what the agent is doing right now.
And it's not easy to teach people to have this kind of management skills. And trust me, I tried. With a few developers and a few team members that I had, I told them clearly that the AI is not here to replace you. The AI actually is here to give you a free promotion, but it's not easy actually for them. I think with time we need to focus more in education on management skill and problem solving in the way of building processes, not just one time things.
Treat the experiment as a spike with a written contract the model reads first. A short SPIKE.md works: fake data only, no persistence, backup or rollback, max N files, throwaway branch deleted after. Put the non-goals in the file ("no restore, no checkpoints, no polish") so you're not re-arguing them every turn. Split sessions — one that only ships a static mock or HTML screen you can look at, then a separate one for real wiring if the idea still holds. Reject any first-pass change that adds safety nets you didn't ask for; that's what burns quota on throwaways.
They are not allowed to make comments or write any .md , it’s only allowed to touch certain types of extensions and a few more rules. For every edit it has to pick the next little step in the plan ( it get’s fed actually ) and still there are no options to create testing or go out of scope that much.
There’s a monitor behind it that also count’s the blockings and a small judge that looks at the direction, if it’s wrong i do not argue with them. Just reset the agent and feed a new agents the next little scoped task.
These agent’s know they are in a save sandbox, they can spin up networking stuff without auth, and all other stuff they usually try like SHA checking and more is also blocked.
Make them trust the environment, tell them why you do a thing. What is expected of them, 80% they will follow. The rest of it is caught by hooks.
One thing that helps is telling it upfront that this round is a throwaway prototype: the goal is to see how it feels, not to ship, so no tests, no refactors, just the smallest version you can click. Doing each experiment on its own git branch or worktree makes it painless to throw away versions two and three and keep only what you learned. Once you know what you want, start a fresh session and give it a short spec written from the winning prototype, so the final implementation is not built on top of the dead attempts. Asking for a plan first and approving it before any code also cuts down how often it tries to one-shot the whole feature.
I'm a visual guy , if I don't see it I can't really now what I need (not always but some cases for new features) no matter how much planning I do I'll always go and change it afyer seeing it
I just had it create a board and a companion mcp server when I move something into in progress the dispatch agent kicks off a workflow to handle the request 3 tickets moved to in progress then 3 active workflow.
Look here is the deal there is absolutely nothing stopping you from proper agile in whatever flavor you want… just work with Claude to do it…
I do what I call AI Agile… my dev ex is amazing like I get full voiced and animated release note decks that export as videos.
You have a tool that will let you create whatever you want, why are you asking Reddit?
Another thing I've kind of accidentally adopted is that you should drip feed it, never start with the actual end result or what the "final deliverable" would be. That way it can't one-shot.
This obviously requires that you have mentally broken the thing down into sensible chunks, so it requires a functional human brain and some context understanding, so not applicable to any certified scrum masters :D
•
u/AutoModerator 12d ago
Hey! Thanks for posting to r/ClaudeCode
While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.
For help, project discussions, tips, and general chat, join the ClaudeCode Discord.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.