PlantUML timeline, Gantt, WBS: project scheduling & breakdown

puml.online

PlantUML is usually seen as a UML-only tool, but it also draws three scheduling views every PM uses: timeline, Gantt, WBS. This article covers all three.

Timeline

A timeline records “what happened on which day.”

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
@startuml
title Q3 2026 launch cadence
concise "Mon" as M
concise "Wed" as W
concise "Fri" as F

@0
M is Jun 21
@30
W is Jun 30 [v0 spec review passed]
@50
F is Jul 10 [code review]
@70
M is Jul 20 [dev kickoff]
@80
W is Aug 1 [staging validation]
@100
F is Aug 10 [production launch]

@end
@enduml

@<percent> is a position on the timeline.

More granular:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
@startuml
title One-month dev schedule
concise "Mon" as Mon
concise "Tue" as Tue
concise "Wed" as Wed
concise "Thu" as Thu
concise "Fri" as Fri
concise "Sat" as Sat
concise "Sun" as Sun

@0
Mon is [<start> 7/1] design
Sat is [7/3] req complete

@5
Wed is [<start> design] api

@10
Fri is [<start> api] integration

@15
Sun is [release]

@20
@enduml

Gantt

1
2
3
4
5
6
7
8
9
10
11
12
13
14
@startuml
projectscale daily

title Launch timeline
hide resources

[Requirements] lasts 2 days
[Design] lasts 3 days
[Development] lasts 14 days
[QA] lasts 7 days
[Integration] lasts 3 days
[Launch] lasts 1 day

@enduml

projectscale daily sets the time unit to days.

Dependencies

1
2
3
4
5
6
7
8
9
10
11
12
@startuml
projectscale daily
title Task dependencies

[Design] as [D] lasts 3 days
[Code] as [C] lasts 5 days
[QA] as [T] lasts 3 days

[Design done] happens at [D]'s end
[Code done] happens at [C]'s end
[Code done] -> [QA start]
@enduml

-> describes a prerequisite link.

Milestones

1
2
3
4
5
6
7
8
9
10
11
12
13
@startuml
projectscale monthly
title Release planning

[Alpha] lasts 14 days
[Beta] lasts 14 days
[GA] lasts 14 days

[Alpha launch] happens 1 days after [Alpha]'s end
[Beta launch] happens 1 days after [Beta]'s end
[GA launch] happens 1 days after [GA]'s end

@enduml

Calendar dates

1
2
3
4
5
6
7
8
9
10
11
@startuml
projectscale weekly

[Project kickoff] starts 2026-08-01
[Requirements] lasts 14 days
[Design] lasts 14 days
[Sprint 1] lasts 21 days
[Sprint 2] lasts 21 days
[Regression] lasts 7 days

@enduml

starts <date> aligns to a real calendar.

WBS (Work Breakdown Structure)

WBS uses tree syntax to decompose a project into sub-tasks.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
@startuml
title Project WBS

* Project kickoff
** Requirements
*** Business req
*** Technical req
** System design
*** High-level
*** Detailed
** Development
*** Backend
*** Frontend
*** Mobile
** Testing
*** Unit
*** Integration
*** UAT
** Deployment
*** Staging
*** Production
*** Canary
** Sign-off
@enduml

* is the top-level node, ** first-level, *** second-level.

WBS with notes

1
2
3
4
5
6
7
8
9
10
11
12
@startuml

* Project kickoff [
Phase 1
----
Overview and direction
]
** Requirements
** System design
** Development

@enduml

[...] attaches a note to the node.

WBS with effort

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
@startuml

* [Project] { total 80 person-days
** [Requirements] { 8 pd
*** Business analysis
*** Competitor analysis
** [Design] { 12 pd
*** High-level
*** Detailed
** [Development] { 40 pd
*** Backend
*** Frontend
** [Testing] { 12 pd
*** Integration
*** UAT
** [Deployment] { 8 pd
}

@enduml

{...} writes a note inside the node.

Sprint 12 plan

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
@startuml
title Sprint 12 plan (Aug 1-14, 2026)
projectscale daily
hide resources

[Requirements review] lasts 2 days
[Design] lasts 3 days then [Development]
[Backend dev] as [BE] lasts 9 days
[Frontend dev] as [FE] lasts 9 days
[Integration] as [INT] lasts 3 days
[Regression] as [TEST] lasts 3 days

[Dev kickoff] happens at [BE]'s start
[Mid-sprint sync] happens at [BE]'s 5 days + [FE]'s 5 days
[Integration done] happens at [INT]'s end
[Release] happens at [TEST]'s end

@enduml

E-commerce MVP WBS

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
@startuml

* [E-commerce MVP] { 30 person-days }
** [Account] { 4 }
*** Sign up / Login
*** Profile
*** Social login
** [Catalog] { 8 }
*** Product list
*** Search & filter
*** Product detail
*** Categories
** [Cart] { 4 }
*** Add to cart
*** Quantity
*** Remove
** [Order] { 8 }
*** Place order
*** Payment integration
*** Order status
*** List & detail
** [Admin] { 6 }
*** Product mgmt
*** Order mgmt
*** Statistics

@enduml

Which view to pick

View Use case Focus
Timeline History, milestones “When did what”
Gantt Task scheduling, dependencies, resources “What’s next, who waits on whom”
WBS Project structure, scope, estimates “What’s in it”

Real projects use all three:

  • Timeline on a wall or company news
  • Gantt in the engineering repo
  • WBS in the requirements doc

Review checklist

Timeline

  • Scale right — days / weeks / months?
  • Milestones explained?

Gantt

  • Granularity right — ≤ 5 days per task?
  • Dependencies explicit?
  • Critical path marked?

WBS

  • 100% rule — decomposed until each leaf is estimable?
  • Estimates reasonable?
  • No overlapping sub-tasks?

Anti-patterns

1. Gantt too granular

1
2
3
4
5
6
7
@startuml
projectscale hourly
title A day of work
[Login logic 1 hour]
[Login API 1 hour]
[Login UI 2 hours]
@enduml

Hourly Gantt is useless — engineers just read Jira.

2. No dependencies in Gantt

Just durations without “who waits on whom” — the schedule will deadlock in practice.

3. WBS without effort estimates

Hierarchy without time/cost estimates isn’t a real plan.

  • Title: PlantUML timeline, Gantt, WBS: project scheduling & breakdown
  • Author: puml.online
  • Created at : 2026-07-29 15:40:00
  • Updated at : 2026-08-14 21:34:29
  • Link: https://puml.online/blog/plantuml-timeline-gantt-wbs-en/
  • License: This work is licensed under CC BY-NC-SA 4.0.