Move an activity and let the chain follow
Free
A dependency means that one record waits for another. In this roadmap, Build the feature waits for Design the feature, Test the feature waits for the build, and Ready for release waits for the test.
Watch a one-week move
The animation moves Design the feature one week later. The build and test follow, retaining their working durations, and the following milestone moves too. Draft announcement has no dependency on this chain, so it keeps its original dates.
The arrows are the illustration of the dependency structure. Select a bar to highlight its chain, or stop the story and drag the design bar yourself. Moving a dependent activity does not move its predecessors: the relationship has a direction.
Add the relationships that matter
- Open Build the feature and, under Depends on, select Design the feature. In List, you can also edit the activity's Depends on cell. Search by name or reference key; tick an option to select it.
- Show dependency arrows in a custom timeline view.
- Drag the predecessor to another date and check the following work.
- Keep independent activities unconnected so they can retain their dates.
Let work overlap
An activity does not have to wait until the previous one ends. Next to each activity it waits for, choose when it may start: after the end, at 75%, 50% or 25%, or at its start. Right-clicking an arrow offers the same choices. The activity moves to that point, and what waits for it moves along, earlier or later. Its arrow leaves the bar there, and it keeps following when the earlier activity moves or changes length. The share counts the earlier activity's days, rounded up, in work days when the roadmap plans in them.
The roadmap uses work-day planning, so a move keeps the same number of work days between activities, and a one-week move here retains the same weekdays. A vacation can make the resulting bars occupy more calendar time; see Planning around vacation.
A dependency is a scheduling relationship, not a grouping relationship. Two activities in the same team or phase do not automatically wait for each other. Tidigar also prevents circular dependency chains.
For another perspective on the same relationships, read The critical line, which pairs a timeline with a synchronized flow view.
How dependency scheduling works in detail
A relationship sets an earliest start
With After it ends, a successor may start on the day after its predecessor ends. In this example, design ends on Friday June 11 and build starts on Monday June 14 because the roadmap excludes weekends. In calendar-day planning, Saturday June 12 would be allowed. Dates include both the first and last day: Monday to Friday is five days of work here.
A successor can start later than its earliest allowed date. This leaves room for a deliberate handover or waiting period. Moving a predecessor carries its successors earlier or later, preserving their durations and the spacing in the plan's calendar, then checking that every dependency is still satisfied. Resizing a predecessor can move the chain too. Dragging a whole bar preserves its duration; changing one end changes its duration.
Moving build does not move design. Moving design does not move the independent announcement. A team, phase, filter or hidden arrow does not create or remove a dependency. Filtering design out of a view leaves its constraint on build active. Dates and relationships belong to the plan; whether arrows are visible belongs to the view.
Several predecessors must all allow the start
If build waits for both design and another activity, both relationships apply. The latest allowed start is the lower bound. When several predecessors move, Tidigar uses the change that puts the successor furthest forward, then checks all its start limits. It does not add the shifts together or promise that every earlier move can pull work earlier: another predecessor may still hold it back.
Adding a dependency pushes a successor later if its current start is too early. If it already starts late enough, its gap can remain. Removing a dependency leaves the current dates in place; it does not undo earlier scheduling moves.
Percentages describe planned time, not reported completion
The overlap choices are At its start, At 25%, At 50%, At 75% and After it ends. For a five-work-day design starting Monday June 7, 50% is three work days, rounded up. Build may therefore start on Thursday June 10. At the start allows Monday June 7; after the end allows the next work day, Monday June 14.
These thresholds use the predecessor's scheduled duration. Changing its progress to 50% does not release a successor or move dates. Changing its dates can change the threshold even if progress stays the same. Work-day planning counts weekdays outside vacation periods; calendar-day planning counts every day.
Changing the overlap choice places the successor at the new threshold, subject to its other predecessors, and moves its following chain. This deliberate change can remove a gap that an ordinary bar move would preserve. To introduce overlap, change the relationship rather than dragging a successor before its allowed start. Partial thresholds apply to activity predecessors; a fixed milestone has one date to wait for.
Remove waiting time deliberately
Open the roadmap's Properties and choose Compact the plan when you want every dependent activity to start as early as all its relationships allow. It preserves activity durations and keeps independent activities on their dates. Following milestones move to the first allowed day after their latest predecessor, skipping non-working days in a work-day plan. Fixed milestones keep their dates.
Compacting applies to the whole plan, including work outside the current filter. It can remove intentional gaps, so review the result before using it for a team commitment. Removing a gap is a separate decision from moving one piece of work.
If a relationship cannot be selected or saved
The picker excludes the activity itself and anything already waiting for it, directly or through a longer chain. Those choices would create a cycle with no valid scheduling order. An activity may wait for other activities or fixed milestones; a following milestone cannot serve as an activity's predecessor. See Two kinds of milestone for these directions.
Imported dependencies must name records that exist and must not form cycles. If validation reports a missing predecessor or a cycle, correct the relationships in the source plan rather than changing dates to disguise it. A scheduling change that would move work beyond Tidigar's supported end date, December 31, 2200, cannot be saved. Resolve the dates or relationship and try again.