Skip to main content

Planning settings

What this page is — The per-project rules Planning works by: how tasks are estimated (hours, points or days), how a size becomes hours, how much of a day is plannable, what the team calls a sprint or a phase, what happens when dates fall outside their phase, and whether a commit tolerates drift. What it is for — Setting the vocabulary once — a team that estimates in T-shirt sizes, a team that estimates in hours and a team that wants hard date containment all use the same workspace. The problem it solves — Without a project-level contract, points mean different hours to different people, capacity assumes a full eight hours of coding, and a sprint can silently run outside its phase. These settings make each of those an explicit choice with a visible default.


Route: /org/projects/<project id>?tab=planning (Project → Settings → Planning, beside Risk Radar) · Permissions: View planning (read), Manage planning (save) Module: Planning · Entry points: Project details → Planning tab · linked from the Capacity and Goals tabs when a default is mentioned


A project can have all of this written for it in one go by the guided set-up; this page is where you change it afterwards.

1. Where the settings apply​

Every setting is per project; there is no organisation-wide inheritance. Until the first save the tab says Using platform defaults until first save.


2. Why you would change the defaults​

  • Your team estimates in points and wants Est. Hours filled automatically.
  • Your work is measured in days — site work, interiors, services — and "12 hours" means nothing to the people planning it.
  • Nobody on the project says "sprint": the work runs in Stages inside Rooms, and the page should say so.
  • Your sprints run in a country with many optional holidays that the team actually takes.
  • Meetings eat a third of the day — a focus factor of 0.65 is more honest than 0.80.
  • The Roadmap is clean and you want block so it stays that way.
  • You commit on Friday afternoons after a busy week and prefer to accept drift rather than rebase every time.

3. Field reference​

Figure 1 — Project settings → Planning: 1 Estimation, 2 Size scale, 3 Focus factor, 4 Date boundaries, 5 Capacity & commitment.

Estimation​

FieldTypeDefaultValidationWhat it does
Estimation unitHours · Story points · DaysHours—Hours: estimate tasks in hours; points are optional. Story points: estimate in points; hours are derived from the size scale or hours per point. Days: estimate in days of work — see Days as the measure
Size scaleTable — Label, Points, Hours (reads Days in days mode; the Points column is hidden); add and remove rowsXS 1 / 2 h · S 2 / 4 h · M 3 / 8 h · L 5 / 16 h · XL 8 / 32 h"Every size needs a label." · "Size labels must be unique." · points and hours in steps of 0.5A task sized with a label gets that row's points and hours. An empty table reads No sizes — tasks are estimated directly.
Hours per pointNumber 0.1 – 200, clearable · hidden in days modeNot set—Used when a task has points but no size label. Blank = derive from the scale
Focus factorStepper 0.10 – 1.00, step 0.050.80—Share of a workday that is plannable; meetings and interruptions eat the rest. A time box may override it on the Goals tab

Date boundaries​

FieldTypeDefaultWhat it does
When a sprint or milestone falls outside its phaseWarn — save anyway and flag it · Block — reject the saveWarnWarn saves the change and returns a warning you can act on later. Block rejects any save that would put a sprint, milestone or task outside its parent's window, or shrink a phase below its children
Hours per dayNumber 0.5 – 24, clearableInheritBlank inherits your organisation's working day (the availability calendar); a value replaces it for this project in capacity and as the length of a "day" when the unit is Days
Auto-schedule due datesToggleOffAt commit, a task with a start date whose estimate or time box changed gets its due date worked out from its days of work — counted in working days on the organisation's week, skipping holidays. The commit preview lists it as a Due date change
Include optional holidaysToggleOffCount optional (restricted) holidays as non-working days when sizing capacity

Under the boundary choice the tab shows a live count:

Switching to block would reject N milestones / M tasks that are outside their window today.

The count is computed each time the tab loads or saves. Bring it to 0 / 0 on the Roadmap and in the task list before choosing block; otherwise the next edit of any of those rows is rejected until its dates are fixed. See the finding codes on Phases, sprints and milestones.

Days as the measure​

Pick Days when the team thinks in days, not hours. Every figure on the Planning page then reads in days — cards, column headers, the Capacity grid, Goals, the Timeline, the burndown, the commit preview — and every box you type into takes days. Under the unit choice the tab says how long a day is: A day of estimate is 8 hours (your organisation's working day), or the project's own Hours per day when set.

What does not change: estimates stay stored in hours. Switching a project to Days (or back) re-reads the same numbers; nothing already planned moves. Typing 2 on a card in days mode saves 2 × hours per day; a project on a 6-hour day and one on an 8-hour day both show "2d" for their own two days of work. Story points disappear from the page in days mode (the Points field, column and card-field), and the task drawer's Effort Tracking reads Estimated days / Remaining days.

Words​

FieldTypeDefaultWhat it does
Sprint · Phase · Backlog · Milestone · Planned hire · ContractorText, up to 40 characters each; blank = defaultSprint, Phase, Backlog, Milestone, Planned hire, ContractorThe word the Planning page uses for each thing — in the Plan by switch, column chips, the Add sprint column, dialogs, notes, the commit drawer and the page guide. A live preview under the boxes reads, for example, Plan by Stages · Rooms, the Wishlist column, "Add stage"

Words are labels only: the underlying types (SPRINT, PHASE), the URL keys (planBy=sprints) and reports do not change.

Money​

Figure 2 — Money: a value per task, the currency, a default day rate and how a stage is billed.

Off by default. Turn it on and every task carries a value; nothing on a project left at None changes.

FieldTypeDefaultWhat it does
Value modeNone · Per task amountNonePer task amount: a card shows what its task is worth, a column adds them up, Capacity shows each time box's value, and a commit records it
Currency3-letter code, clearableInheritBlank uses the project's currency, else your organisation's
Default daily rateNumber, clearableNot setOffered when a person or contractor has no rate of their own
Invoice modeOn completion · ProgressOn completionHow this project bills: the whole stage when it is finished, or what has been earned since the last bill — see Invoicing a time box
Customer for invoicesSelect — the Books customersNot setWho this project's invoices are addressed to. Planning cannot raise one without it

How a task is valued. Each value carries a basis:

  • Fixed — a price you type.
  • Rate — the day rate of whoever the task is planned on × its days of work. It is re-worked whenever the days or the person change, so it can never go stale; a task with nobody rated on it reads No value.
  • Quantity — quantity × unit rate (120 sqft × ₹450).

The amount is always stored, whatever the basis, so a report never has to recompute it. A fixed price and a quantity line are your numbers and are never overwritten; only the Rate basis follows the plan.

Where rates come from. A member's day rate is the project's resource rate (Project → Billing; an hourly billing configuration is multiplied by hours per day). A planned hire's or contractor's rate is part of the resource itself and is edited there. Planning → Define → Rates lists them all and says which is set where. A contractor quoting another currency cannot value a task until it has a rate in the project's currency.

Capacity and commitment​

FieldTypeDefaultWhat it does
Underload ratioStepper 0 – 1, step 0.050.60Planned ÷ capacity below which a person counts as under-allocated for the sprint (the Under state). The over side uses the Risk Radar's overload ratio
Commit requires no driftToggleOnA scenario can only be committed when every task's plan matches its current estimate and dates — the commit drawer says Drift must be zero to commit (project setting). Off turns drift into a warning you acknowledge
Skill areasTags — type and press EnterEmptyThe project's vocabulary (Backend, QA, Design…) offered on each row of the Capacity grid; a label to match tasks to people, not a restriction

4. Worked example​

An interior-design studio plans a flat: unit Days, Hours per day left blank (the organisation works 8-hour days, Monday to Saturday), Words: Sprint → Stage, Phase → Room, Backlog → Wishlist, Planned hire → Planned crew. The Planning page now reads Plan by Stages · Rooms, a card for "Wardrobe carcass" shows 3d, the Kitchen room column reads 18 / 24d, and the crew's capacity grid reads days per week. Auto-schedule due dates is on, so committing the plan sets each task's due date from its start and its days of work, skipping the two public holidays that month.

A new software project starts in Story points. The lead keeps the default scale but changes M to 6 hours because the team's medium tasks come in under a day, and sets Hours per point to 2 for tasks that get a raw number. Focus factor goes to 0.70 — two ceremonies a day. She leaves the boundary at Warn: the tab reports Switching to block would reject 1 milestone / 3 tasks. Over the week the team fixes the four dates on the Roadmap; the count reads 0 / 0 and she switches to Block. She turns Commit requires no drift off because the project commits every Friday after a week of live changes and prefers to acknowledge the drift warning. Skill areas: Backend, Frontend, QA.


5. The admin contract​

  • Reading the tab needs View planning; Save needs Manage planning (the form is read-only without it).
  • The tab appears only on projects whose package includes the Planning module.
  • The overload ratio and the commit severity band are Risk Radar settings on the same Project settings page.
  • Members' hours per week, holidays, zones and the work week are set elsewhere (Roadmap capacity table and People settings); this tab only decides how they are combined.

6. Don't confuse this with…​

  • Project timesheet settings — governs how time is logged; Planning's hours per day override inherits its daily figure when blank.
  • Risk Radar settings — thresholds for the radar, including the overload ratio Planning reuses.
  • Task Configuration — statuses, types and priorities; nothing here changes them.

7. Troubleshooting​

SymptomCauseFix
No Planning tab on the projectYou lack View planning, or the package has no Planning moduleAsk your administrator
Save is disabledYou lack Manage planningAsk for the permission
A card reads "No value" on the Rate basisNobody with a day rate is planned on itPlan someone on it, or set their rate (Project → Billing for a member, the resource itself for a hire or contractor)
Money is on but no figures appearThe tasks have no value yetValue them on the board — click a card's value line, or use the card menu's Value block
"Size labels must be unique."Two rows share a label (case-insensitive)Rename one
Est. Hours are not derived from pointsUnit is Hours and the task has no size label and no Hours per pointSet Hours per point, or switch the unit to Story points
A card reads 2.5d for what should be two daysHours per day is inherited from the organisation's calendar and differs from what you expectSet the project's own Hours per day, or fix the calendar in People settings
Words changed but the sidebar still says "Planning"Words rename things inside the Planning page onlyExpected — the module name is not a project setting
Roadmap saves suddenly fail on datesSomeone switched to Block while rows were still outside their windowFix the dates, or switch back to Warn
The rejection count does not go downThe rows are fixed but the tab has not reloadedReopen the tab