Sprints

A project in Planning Studio can work with sprints. A sprint is a time box over the same board: the same columns, the same limits, the same items. For a new project choose Sprints under Works with; an existing project is switched on its backlog, with a confirmation. A project without sprints notices nothing.

Where to start

Open Backlog and sprints in the sidebar of Planning Studio. It lists the teams and projects that already work with sprints, with their running or next sprint and links to the backlog, the sprints and the retro. If you have nothing yet, a three-step explanation shows: create a team (or turn on sprints on a board you already have), add items to the backlog and estimate them in points, create a sprint with a goal and start it.

Converting a board. Every board has a Backlog and sprints card with Turn on sprints. The board stays the same: the same columns and items.
See how it works first. Add example project with sprint (on Projects and on Backlog and sprints, for anyone who manages Planning) adds a ready-made example to your workspace: a board with a backlog, a finished sprint with a retro and a running sprint with a burndown. It is added once, you can change everything and archive the project whenever you like.

Teams: each with its own backlog and sprints

An agency often has more than one team, for example a websites department and a webshops department. In Planning Studio a team is an internal project that works with sprints (a project without a client). Every team has its own backlog, sprints, sprint times, capacity, standup and retro; what one team plans does not touch another. Two teams may plan the same weeks, and an item can only go into a sprint of its own team.

New team on the Projects overview creates an internal project with sprints. Teams appear there under Teams, with their running or next sprint, its goal and progress; client projects are listed separately under Client projects.
The team switcher at the top of every project screen jumps to the same screen of another team, without going back to the overview.
The rhythm belongs to the team. A new sprint starts after the last sprint of this team and lasts just as long; the screen says so.

People in a team

A team has people, and you add them in two places that each do something different. A staff member's account (invite, role) lives under Access in the sidebar. Whoever works in a team must then also exist as a person in the agenda. On the team's Team tab you choose that person, with their hours per week and optionally a role; that gives the capacity in points. Hours and availability per staff member (working days, absence) are managed under Team schedule. Relations is not for staff: it holds clients, leads and contacts.

In the sidebar your teams are under Planning, Teams; if there is no team yet, a line says so and you can start with Create new team. Each team has Dashboard, Backlog, Sprints and Retrospectives, each on or off and in your own order (see Customizing the sidebar).

Backlog and sprints side by side

The backlog is a list, as in Jira. On the left are the epics (collapsible): each epic with its colour, the number of open items and its progress in points, and a click filters the list on that epic. On the right are first the sprints (the running and upcoming ones) with their items, and below them the backlog.

A row shows type, key, title, labels, epic, the column the item is in, deadline, points and owner. A click on the title opens the whole item in a window or drawer (?item=KAL-12), without leaving the list. On a narrower screen the counters disappear first, then the labels.
Dragging: an item to a sprint or back, and up or down in the backlog. Anyone who cannot drag uses the menu of the row (To the top, Up, Down, Move to) and every move is read aloud. An item is in its new place at once; if the server says no, it goes back.
Several items are chosen with the tick box. You then move them together to a sprint, assign them to someone, give them points together or add or remove a label.
Quick filters above the list: My work, Without points and Without criteria, each with the number of open items it covers. They combine as "and".
Suggest points (for open items without points): a suggestion from similar finished items in this project, the median of their points, with those items as the reason. It is not an estimate by a model and costs nothing. Nothing changes until you accept a suggestion yourself; without similar work it says so and does not guess.
Quickly creating an item is possible at the bottom of the backlog: type a title and press Enter. You fill in the estimate in the list.
Per sprint the points are shown against the capacity of the team (from hours per week and absence, see below). Over the capacity the heading says so in words. If the capacity is unknown it says "capacity unknown", never a zero; and when some items have no points it says how many, because the total is then a minimum.
New sprint is at the top of the list. The goal is required: one sentence about what will be done. Start and end are filled in from the rhythm of the team and you can change them. A sprint without a goal is not created, and the sprints of one team do not overlap.

Backlog and epics

The backlog is everything that is not done and not in a sprint, from most to least important. Higher is more important, and that order also applies in the sprint.

Points are 1, 2, 3, 5, 8, 13 or 21. An item without an estimate is listed, but cannot go into a sprint. Above 8 we ask you to split it.
Moving is done by dragging or with the menu of the row: to the top, one place up or down, and to a sprint.
An epic groups items around a client goal, with a colour and its progress in points. An epic can only be completed when its items are done. You create and complete epics under Manage epics in the panel on the left.

Sprints

A sprint has a number, a one-sentence goal, a start and an end. Sprints do not overlap, at most one runs per project, and at most twenty can be planned.

Starting needs a goal and at least one item. The page of a planned sprint has the Start sprint form: the goal and the dates (which you can still adjust there), and above it a warning when items are not ready for the sprint yet. At that moment the points are fixed for the burndown. A sprint that is already running, or that touches another sprint, does not start.
Ready for the sprint is an agreement of the team (see below). The warning counts the items without points, without acceptance criteria or without an owner (a person or an agent) and shows at most fifty, with how many more there are. It is a warning: you can still start.
Added during the sprint: what you add after the start counts separately in the burndown, so the team does not look slower than it is. What you remove stays visible as removed and does not count as done.
Closing takes three steps. Review: the points that are done against what was planned at the start, the number of finished and open items, and the team's Definition of Done as a reminder. Open items: for each open item you choose Backlog, Next sprint or Leave it; an item without its own choice follows the default (the next sprint if there is one, otherwise the backlog) and Everything to the backlog puts all of them back in one click. With more than two hundred open items the first two hundred are listed and the rest follow the default; the screen says so. Confirm: an overview of what goes where, and only the Close sprint button changes anything, all at once: if it fails, the sprint keeps running and nothing moves. Afterwards the result is shown with a link to the retro. Leave it puts the item back in the backlog marked Left in place (with a filter of that name); the closed sprint keeps that it was not done and no longer counts it later. A finished item with an open criterion counts as done and is mentioned.

Team agreements

On the Team tab you find Team agreements (setting them needs the right to manage, anyone who can see the sprints can read them):

Ready for the sprint: which rules warn when starting: every item has points, acceptance criteria and an owner. All three are on by default.
Definition of Done: short points for the whole team (at most twelve of 120 characters, one per line), for example Tested or Documented. They appear as a checklist when closing a sprint. It is a reminder: nothing is saved and nothing is blocked.

Sprint planning and capacity

On a sprint's page the backlog sits next to the sprint. You put an item in the sprint by dragging it: grab it by the handle at the left of the row and drop it in the sprint. Taking it out works the other way round, and in the backlog you drag up or down to change the order. There are no buttons for this. Without a mouse, hold Alt on the handle (Tab to it) and press arrow right (into the sprint), arrow left (back to the backlog) or up and down (place in the backlog); a message reads out where the item is now. Escape cancels a drag. An item without points cannot go into a sprint: it stays where it is and the message tells you to estimate it first. The sprint itself keeps no order of its own: items appear in backlog order. If the server says no, or someone else just moved the item, the item goes back and the message says why. Capacity and totals update straight away. For each team member a bar fills with points against their capacity:

Capacity is hours per week times the number of weeks, minus days off, times 75 percent focus, divided by 4 hours per point. A day off is a whole working day; weekends do not count.
Unknown is unknown. Someone without hours has an unknown capacity, not zero, and then the team's capacity is unknown too. Unknown counts as full.
Over the limit is possible, but the bar and the text say so, and whose it is. It is a warning, not a lock.
Agents do not count. Crew work is in the sprint and counts towards the goal, but not towards people's bars.

An admin sets hours, role and absence under Team. For absence we only store from and to, never a reason or a kind: that someone is sick is health data and does not belong in Planning.

Acceptance criteria

An item's page lists its acceptance criteria: sentences that can be checked, preferably as Given, When, Then. At most thirty per item, each up to 500 characters. The counter also shows in the lists (2/4).

Adding or removing a criterion gives the item a new version: an agent that built against the old version will not deliver. Ticking one off does not.
Done with open criteria asks for a confirmation. If you move such an item to Done on the board, you land on the item's page and choose Done anyway there.

Proposal from the director in an item

An item shows the block Proposal from the director as soon as there is a proposal. A proposal is a text or a value for one part of the item: a new description, acceptance criteria (at most ten, each a sentence that can be checked) or points. The director makes the proposal, or a calculation rule does: Suggest points takes the median of similar items that are done and names those items as the reason. Without similar work there is no proposal: you enter the points yourself.

A proposal never changes anything by itself. You choose per proposal: Accept adopts it, Edit lets you change the text or the points first, Ignore closes it without consequences. You decide on a proposal once.
Check it. A text from the director was made by a model and can be wrong or incomplete. It is shown as plain text with its reason. Read it before you adopt it; a proposal that looks good is no proof that it is right.
A proposal cannot set the risk, the owner or the sprint of the item. If a proposal you adopt changes the description, the usual rule applies: the risk a person set earlier lapses, and you set it again.
If the title or the description changed since the proposal, a proposal for the description or the criteria no longer fits and you ask for a new one. An item gets at most six proposals per day.
The item's history shows who adopted or ignored a proposal, without the text.
A proposal is plain text: links, images and addresses with a scheme (such as https://) are not accepted. A proposal also no longer fits an item that has since been completed or is in an archived project.

Test plan on an item

An item has a Test plan block: the steps you use to check that the work is right. Each step has what you do, what you expect and a result: open, passed or failed (with a short remark, for example what went wrong). A result shows who set it and when. A test plan has at most fifty steps. Above the steps it says how many passed ("3 of 5 passed"); that is also what the test report will show later.

A test plan is internal. It belongs to the item only. A client who looks along, replies or opens a link never sees a step or a result, even if you share the item.
Make a test plan from the criteria makes a proposal with a rule, without a model and at no cost: one step per acceptance criterion, "Controleer" (check) followed by the criterion, and the criterion itself as the expected result. You accept or ignore it; the steps only exist after you accept. A criterion that already has a step is not added again, and a criterion with a link or markup is skipped and mentioned. If the criteria changed in the meantime, the proposal no longer fits and you ask for a new one. An item has one open proposal.
A result is a decision. A step that has a result is reopened first before you pick another result; that way two people do not silently overwrite each other. If you change the text of a step, its result goes back to open, because the step is no longer what you tested.
Managing steps works while the item is not done: add, change, move up or down and remove. On a finished item you can still set results. In an archived project nothing changes any more.
A step is plain text: links and markup are not accepted. The item's history shows who did what, without the text.
What does not exist yet: a test report with a pdf in your client's house style. That comes later; the test plan is its content.

Burndown

The burndown shows how many points are left on each working day. The dashed line is where you should be, the solid line where you are, and work that was added shows as a dotted line with the amount. Every point can be reached with the keyboard, and Show as table gives the same numbers as a table.

The chart reads a daily snapshot that is recorded on every change, not the board as it is now. It says something about the work, not about who did it.

Retro

After completion the retro opens with three columns: Went well, Could be better and Actions.

Anonymous is on by default. An anonymous card does not store its writer: that is not a display choice, the writer is not saved.
Three votes per person per retro. You see how many votes a card has, not whose.
An action gets an owner and becomes, with Make item, an item at the top of the backlog, labelled retro. An action without an owner is a wish and does not become an item.

Three helpers sit at the top of a retro, without any window:

Look back. In Write (and in a retro without steps) the panel What did we do with the actions from the last retro? shows each action of the previous completed sprint with its text, owner and state: done (the item is finished), in progress (the item is open) or no item yet. Read only. If there is no earlier retro, a line says so.
Check-in. In Write you pick one of five faces for how the sprint went. It is anonymous, you pick one, and you can change or withdraw your choice until the next step. From Reveal on, the page shows how many people chose each face, as counts. Never who, and deliberately no average: an average says little in a retro.
Timer. Whoever started the retro, or may manage, starts a timer of 3, 5 or 10 minutes, or your own number from 1 to 30 minutes. Everyone sees it count down; the time comes from the server, so a wrong clock does not matter. Sound is off by default. You can stop it at any time, and every next step starts without a timer.

Planning ahead

Under Plan ahead the Planner spreads the backlog over the coming planned sprints (one to ten). It is a proposal: nothing changes until you accept it, completely or per item. Each placement says why: the position in the backlog, how much room is left, a deadline. What does not fit stays in the backlog with the reason: no estimate, no criteria, too large, no sprint in time for the deadline, or an unknown capacity. Accepting recalculates the proposal, so it does not act on an old state. The same proposal can be read through our MCP (planning_sprints_vooruit_plannen), read only.

Proposing a sprint

On the Backlog you will find Propose a sprint. Pick a planned sprint and the proposal appears: items from the backlog, chosen by deadline (a deadline in the sprint, or already past, comes first), then priority, then risk and then the position in the backlog, as long as they fit what the team can carry. Each item says why. You see the total, the room left, what does not fit and what needs an estimate first. Untick an item to leave it out and confirm: only then do the items go into the sprint, and each item can be moved back on its own.

It is a proposal based on points and staffing, not a forecast. Capacity comes from the weekly hours of the team members, minus absence, with 75 percent focus and 4 hours per point. If a team member has no hours filled in, or there is no team, the capacity is unknown and nothing is proposed: unknown never counts as enough. Items without points do not count and are not estimated for you. Impact and velocity do not count yet. When you confirm, the server recalculates the proposal; only items from that proposal go in. The same proposal can be read through our MCP (planning_sprintvoorstel), read only.

The crew in the team

Team also lists the agents. They can receive an item, but have no capacity: they have a limit per project.

How many at once: when full, the agent gets no new item.
Paused: the agent takes nothing new, not even work that was already waiting for it.
Risk: with a rule, only an item with a risk set by a person, at most the rule's highest level (R1 or R2), goes to that agent. Never an item without a risk or with R3. If you raise the risk later, the agent no longer picks it up.
Costs: a monthly cap per agent, checked beforehand, and the costs this month. Excluded labels, a required criterion and more are in The crew, release notes and recipes.
Take back removes an item from the crew.

Who can do what

Everyone in the workspace (except a client as a guest) sees the sprints. Planning, estimating, criteria, starting, completing and the retro need the right to plan. Hours, absence and an agent's limit need the right to manage. Giving an item to the crew or taking it back needs the right for the crew.

Via MCP and the director

For a project with sprints there are tools for what you do in the screen (right planning.plannen unless stated otherwise):

Read: planning_backlog_lezen, planning_sprints_lezen (with a sprint number also the items), planning_teams_lezen, planning_teamafspraken_lezen (ready for the sprint and the Definition of Done) and planning_recepten_lezen.
Plan: planning_sprint_plannen, planning_sprint_starten and planning_sprint_afronden (unfinished work goes back or on, chosen per item with keuzes, all or nothing; leaving it in place is only done by a person in the screen; nothing disappears). planning_items_verplaatsen puts items in a sprint or back in the backlog; an item without an estimate cannot join.
Team (planning.beheren): planning_team_maken and planning_team_wijzigen set members with hours per week and a role. The rules per agent (ceiling, risk, WIP) are only set by a person in the screen.
Recipes: planning_recept_schakelen turns a recipe off. Turning one on is only done by a person: a recipe is a standing rule.

Giving a task to the crew and archiving a project are proposals that a person with the crew right or a planner signs. Titles are under onvertrouwd.

Proposals for an item: planning_voorstellen_lezen, planning_voorstel_maken (stores a proposal, the item does not change) and planning_voorstel_beslissen (accepting asks for a signature under Approvals, also in an automatic mode; ignoring closes the proposal).
Test plan of an item: planning_testplan_lezen, planning_testplan_zetten (creates or changes steps, all or nothing; removes nothing and sets no result) and planning_teststap_resultaat (sets the result of a step; your key shows as the one who set it). The test plan is internal.