Sprint Planning With AI: A Workflow That Keeps People in Charge

Sprint planning with AI works best when the assistant does the preparation and people make the choices. Before the meeting, an assistant connected to your board can refine the backlog, flag duplicates, ask the questions that make vague items ready, gather what is known about each item’s size, and draft two or three candidate sprint goals. In the meeting it answers questions about the backlog on the spot. It does not choose the goal or the scope: in Scrum those belong to the team, and a plan the team did not make is a plan nobody feels bound by.

What the Scrum Guide actually asks for

It helps to be precise, because a lot of sprint planning habits are not in Scrum at all. The 2020 Scrum Guide↗ (opens in a new tab) describes Sprints as fixed-length events of one month or less, and Sprint Planning as the event that starts one, timeboxed to at most eight hours for a one-month Sprint. It addresses three topics: why this Sprint is valuable, what can be Done this Sprint, and how the chosen work will get done.

• The whole Scrum Team collaborates to define the Sprint Goal.
• The Developers select items from the Product Backlog, through discussion with the Product Owner.
• The Developers plan how to do the work, often by decomposing items into smaller work items of one day or less.
• The Product Owner is accountable for ordering the Product Backlog; the Developers who will do the work are responsible for sizing.

The guide calls the tidying-up beforehand Product Backlog refinement: breaking items down and defining them more precisely. It does not mention story points or velocity; it says the more the Developers know about their past performance, their upcoming capacity and their Definition of Done, the more confident their forecast will be. Every one of those decisions has a named owner, and none of the owners is a tool. That is the frame for everything below.

Before planning: refinement with an assistant

Refinement is where an assistant saves the most time, because it is mostly reading. Connect it to the board with read and comment access, which is enough for all of this, and give it one job at a time.

Find duplicates

Backlogs collect the same request filed three ways. Ask the assistant to go through the backlog and comment on each suspected duplicate, naming the item it repeats, and to delete nothing. A person merges. On fenbs, new duplicates are also held back at the door: when an assistant files a task with fenbs_create_item and an open one, or one finished in the last fourteen days, looks like the same thing, nothing is filed and the likely matches come back instead.

Make items ready

For each item near the top, ask the assistant to comment the one question that would make it ready to plan: which screen, what should happen instead, how anyone will know it is done. The owner answers. The assistant does not rewrite anybody’s problem statement.

Split what is too big

Items that cannot fit in a Sprint need breaking down before the meeting, not during it. The assistant can propose a split into smaller, outcome-shaped items and write it where people can read it; the team approves or changes it. AI agent task decomposition covers how to judge a split.

Gather sizing evidence, not sizes

The Scrum Guide gives sizing to the Developers who will do the work, so an assistant should not assign estimates. It can do the research that makes estimating quicker: list similar items finished before and how long they took from start to Completed, name the files or screens an item touches, and point out unknowns. The Developers then size with better information, and quickly.

Read the To Do lane, highest priority first, and stop after 15 items.
For each one:
- If it looks like a duplicate of another task, comment the ref it repeats.
- If it is not ready to plan, comment the one question that would make it ready.
- If it looks too big for two weeks, comment a proposed split. Do not file it.
- Comment two similar finished tasks, and what the item touches.
Do not change any task, lane, priority or estimate.

Drafting a sprint goal

A useful Sprint Goal is one sentence that says why the Sprint is worth doing, so that the team can make trade-offs against it when something unexpected lands. An assistant is good at proposing candidates from what is at the top of the backlog: “Customers can pay invoices online by card”, “New users reach their first board without help”. Ask for two or three, each with the items that would serve it.

Then treat them as drafts. The goal is the team’s commitment, and it often turns on things the board does not show: a promise to a customer, a date a partner is working to, a risk someone wants retired early. Pick one, rewrite it in your own words, or throw all three away. On fenbs you can record the goal the team chose on the Decisions page, with who decided it and why, so an assistant working later in the Sprint can read what it is for. The deciders on a decision are always people; an assistant can write one down but is never the one who decided it.

Capacity notes

Forecasting depends on how much capacity the team actually has, which changes every Sprint: holidays, a conference, someone on support rota, a release that will eat a day. An assistant cannot know most of that, but it can collect it. Ask each person to note their availability, and have the assistant set it next to what the team finished in recent Sprints and the size of the candidate items. The output is a page of facts for the team to reason from, not a number to accept.

Be wary of any tool, assistant or otherwise, that turns capacity into an automatic commitment. The Scrum Guide describes a forecast made by the Developers, and the value of the forecast is that they made it.

During the meeting

Keep the assistant as a fast reader in the room, not a participant with a vote. Useful questions to ask it while the team is deciding:

• “What else on the board touches invoicing?” before committing to an item in that area.
• “Which of these items has an open question in its comments?” before selecting it.
• “Is there a recorded decision about retries?” before someone reopens a settled argument.

After the meeting, the assistant can do the clerical part: file the approved splits, write each selected item’s plan from what was said, and link related items together. Give it write access for this step if it did not have it, or have a person do it.

Running a sprint on a board without sprints

fenbs has no sprint feature, no story points and no velocity chart, on purpose: it is a simple board with four fixed lanes, To Do, Next Up, In Progress and Completed. If your team works in Sprints, the lanes carry them without anything extra.

• To Do is the Product Backlog. Priority, from 1 (most urgent) to 10, and the lane’s own sort order carry the ordering the Product Owner sets.
• Next Up is the Sprint. At planning, move the selected items into it and order them with the Shared order sort (called Custom on a personal board); that order is shared with everyone on the board, assistants included.
• In Progress and Completed are the work during the Sprint. An assistant takes only from Next Up, which keeps the scope the team chose.
• A category or project named after the Sprint, such as “Sprint 14”, lets you filter to it later. Both are made by typing a new name in a task’s editor.
• The board’s History records every move with who made it and when, so the review has a list of what changed without anyone reconstructing it.

An item that is not finished at the end goes back to To Do to be ordered again, or stays in Next Up if the team selects it again. Either way the move is a line in History.

What to keep away from the assistant

• Choosing the Sprint Goal or the scope. It can propose; the team decides.
• Assigning estimates. Sizing belongs to the people doing the work.
• Reordering the backlog on its own. Ordering is the Product Owner’s accountability.
• Moving items into Next Up. On fenbs, moving between lanes is its own permission, so an assistant connected with read and comment only cannot do it at all.