Dependencies
What this page is — The two steps of Plan by → Dependencies: mapping what waits for what, then fitting the sprints around it. What it is for — Planning an order of work — what has to finish before what — and checking that the plan you are about to commit actually honours it. The problem it solves — A plan can look full and balanced and still be impossible, because a story sits in a sprint that starts before the work it waits for is finished. Capacity will never show that; it only shows hours. Here a link that cannot hold is drawn in red, and the story that waits carries the reason and the move that fixes it.
Route: /org/tasks/planning → Plan tab → Dependencies · Permissions: View planning (read), Manage planning (draw links and move stories)
Module: Planning, under the Task Management category · Entry points: the Plan by row of the Plan tab
1. The two steps
| Step | What you do there |
|---|---|
| Identify Dependency | Draw the links. An open canvas of story cards: drag one in from the rail, draw a line from the story that must finish first to the one that waits, click a line to cut it. |
| Adjust Sprint | Fit the plan around them. The plan laid out as columns, with the links drawn across it, so an impossible order shows up — and a story can be moved to another sprint on the spot. |
The switch sits next to Dependencies in the Plan by row, and the page remembers which one you were last on.
Links live in the scenario like everything else in Planning: nothing reaches the live tasks until you press Commit, which writes them as predecessors on the tasks.
2. Why you would use it
- A plan that is full is not the same as a plan that can happen. Capacity counts hours; only the links tell you that the wiring cannot start before the walls are up.
- Answer "why does this start in November?" in one screen — the client sees the chain, not a spreadsheet.
- Fix it where you see it. The story that waits carries the move that puts it right, so an order problem is corrected in the same screen it appears in, before anyone is told a date.
- Nothing is risked while you try. Links and moves live in the scenario; the team's board is untouched until you commit.
3. Identify Dependency — mapping what waits for what
- The left rail lists the scenario's stories and is searchable. Drag one onto the canvas, or use the link icon on it.
- Drag from the edge of a card to another card to draw a link. It points from the story that must finish first to the one that waits.
- Click a link to cut it.
- A card reads Blocked when it waits for something unfinished, and Blocking when something unfinished waits for it.
- A link you added is drawn in the primary colour, one that already exists on the live tasks in grey, and a live link you cut is dashed red and reads removed on commit.
- A link that would make a story wait for itself is refused, both as you draw it and again at commit.
Where the cards sit is saved with the scenario, so everyone sees the same picture. The canvas is not available on a phone.
Links are drawn and cut here, not in Adjust Sprint. Adjust Sprint is for fitting the sprints around the links you already have.
4. Adjust Sprint — the plan as a board
One column per iteration and one row per category, so the lines have room to be followed:
- Columns run in date order: the Backlog first, then each phase as one heading with its own sprints as columns inside it, then any sprint that belongs to no phase. A phase with no sprints is a column of its own. Stories placed on a phase itself get a Not in a sprint column inside that phase.
- Rows are the categories, named down the left with their colour and a count. Stories with no category share a No category row. Switch to Rows: None for a single row.
- Only stories that have a link appear here.
What the lines mean
| Line | Meaning |
|---|---|
| Grey | In order — the story that waits sits in an iteration that starts after its predecessor's ends. |
| Red | Out of order — the plan asks the story to start before the work it waits for is finished. |
| Dashed amber | It waits on work that is not planned yet. |
A predecessor that is already done is never a problem, whatever the dates say. Two stories in the same column are joined top to bottom.
Needs attention, on the left, counts the links and lists every problem in words, naming both iterations and their dates.
Moving a story
Drag a tile to another column, or click it and choose a sprint in Planned in. Either way the story is re-planned in the scenario, exactly as on the plan board, and every other Plan by view shows the new sprint straight away. The lines redraw as you go.
5. The story that waits — field reference
Click a tile for the whole picture: the full title, the estimate, the sprint it is planned in, Quick view to open the task drawer — and, when something is wrong, the reason and the move that fixes it.
A tile carries a warning sign in two cases: red when what it waits for ends after its own sprint starts, and amber when what it waits for is not planned yet.
The suggested move is the smallest one that puts the link back in order — the earliest iteration that starts after the other story ends, or failing that, moving the predecessor to the last iteration that ends before this one starts. Two things are worth knowing about it:
- It is checked against every link in the plan. A move that would merely break a different link is not offered.
- It moves the chain when it has to. If other stories wait on the one being moved, they move too, and the button says how many — Move … and 3 more. Rest the pointer on it to see every move it will make. They are applied together.
When no iteration in the plan would work, the panel says so instead of offering a bad move: that needs the dates changing on the Roadmap.
6. Categories
The Categories button in the left panel shows the same plan one level up — useful when a client asks why a stage starts when it does.
- Each category is a bar, from the iteration its first planned story sits in to the iteration of its last. Stories that are not planned yet do not stretch it.
- A category follows another whenever one of its stories waits for one of the other's. The line carries the number of story links behind it.
- A bar is red when it starts before the category it follows, and amber when the two overlap.
Links you keep by hand
The lines are worked out from the stories, but you can overrule them, and the choice is saved for the project:
| You want | Do this |
|---|---|
| A link the stories do not imply | Pick the two categories under Add a category link and press Add link. It is drawn dashed and labelled added by hand. |
| To remove one you added | Click its line, or press the cross beside it in the panel. |
| To hide a link the stories do imply | Click its line. It moves to Hidden by hand and is no longer checked. |
| To bring a hidden one back | Press the circular arrow beside it under Hidden by hand. |
A pair the stories already link cannot be added — the button explains why rather than saving something that would never be drawn.
7. Worked example
A fit-out plan has Light points planned in Electrical (12 Nov – 25 Nov) and Kitchen units in Kitchen units (1 Dec – 10 Dec), and the light points wait for the units. Adjust Sprint draws that line red and Needs attention reads 6 links · 1 out of order.
The planner clicks the Light points tile. The panel reads Waits for the kitchen units, which ends 10 Dec — after Electrical starts 12 Nov, and offers Move … to Installation, the first stage starting after 10 Dec. Pressing it moves the story, the line turns grey and the panel reads all in order.
Had Snag list also waited on the light points, the button would have read Move … and 1 more: the snag list would move out with it, in the same step, because moving the light points alone would only have turned a different line red.
Nothing has reached the team yet. The planner opens Commit, checks the analysis, and commits: the sprints are written onto the tasks and the links are written as predecessors.
8. Before you commit
- Open Adjust Sprint and read the count at the top of Needs attention.
- Fix what is red, either with the suggested move or by moving stories yourself.
- Look at the dashed amber links — those wait on work nobody has planned; plan it, or accept that it is a risk.
- Commit. The links are written onto the tasks as predecessors, and the commit drawer lists them.
9. The admin contract
- Permissions. Reading needs View planning; drawing links, moving stories and keeping category links needs Manage planning. A committed scenario is read-only whatever your permissions.
- Sprints and phases need dates. A link can only be judged against a start and an end date; a time box without them is treated as no constraint. Dates come from the Roadmap, or from the scenario's own time boxes.
- Categories come from the tasks. The rows and the Categories level use the category on each story, so a project whose tasks have no categories gets one No category row. Categories are configured in Task Configuration.
- Category links are per project, not per scenario: one kept by hand applies to every scenario of that project.
- The Backlog column is a column like any other, and a story dropped there is simply not planned yet.
10. Don't confuse this with…
- Capacity — whether the people have the hours. Dependencies is whether the order is possible; a sprint can be comfortably staffed and still impossible.
- Blocked in Task Management — the live flag on a task, written by a commit. Here everything is still a draft.
- Phases, sprints and milestones — where the dates themselves are changed. Dependencies never moves a date.
11. Troubleshooting
| Symptom | Cause | Fix |
|---|---|---|
| The board is empty and offers Identify dependencies | The scenario has no links yet | Map them on the canvas first; only stories with a link appear here |
| A story I expect is not on the board | It has no link | Draw the link, or look at it on the plan board |
| A line is red although the work is finished | The predecessor is not marked done in the live task | A done predecessor is never flagged; check the task's status |
| A line is dashed amber | What it waits for is not planned in any iteration yet | Plan the predecessor, or accept it as a risk |
| No suggested move, only a note about the dates | No iteration in the plan starts late enough | Change the dates, or add an iteration, on the Roadmap |
| The suggestion moves several stories | Others wait on the one being moved | Rest the pointer on the button to see every move before you press it |
| A category bar spans more columns than I expect | One of its stories is planned far out | Open the Tasks level and look for that story |
| A category link will not add | The stories already imply it | Nothing to do — it is already drawn, from the stories |
| I moved a story and nothing changed on the team's board | The plan is a scenario | Commit when you are ready |
| Everything is read-only | The scenario is committed, or you lack Manage planning | Clone the scenario; ask for the permission |
A red line is not always wrong. Sometimes the right answer is a different sprint date rather than a different sprint, and dates are changed on the Roadmap or in the scenario's own time boxes — see Phases, sprints and milestones.
12. What this view does not do
- It does not draw or cut links — that is Identify Dependency.
- It does not change any date. Every suggestion moves stories between iterations that already exist.
- It shows only stories that have a link. The full plan is on the plan board.
- It never touches the live tasks. Until you commit, everything here belongs to the scenario — see Scenarios and commit.
Related: Planning workspace · Phases, sprints and milestones · Capacity · Scenarios and commit