It can look like repetitive, but I come again with the same question from here about WBS and planning deliverables.

I was "advised" in a meeting recently to include a planning deliverable leg. And a WBS deliverable at n-level if I want to measure time, cost, tasks and resources later.

As far as I know, WBS is equals to Scope of the project. Schedule are the activities to produce a deliverable, thus there is a strong relation between both. A block of activities that are not related to a deliverable it may be wrong and should be included in or update the WBS.

As far as we are in the planning phase of the project, there is no problem to update the WBS. In the contrary, if WBS got approved, the only way to update it is through a formal change process.

Should I include a WBS deliverable at n-level within my Planning leg of my global WBS in the early stages of the project? (Let's say when the project team is building it with post-it notes).

I know that it is an error to include SO MUCH DETAILS in the WBS or activities as long as we can measure progress and fulfill with the objective of the deliverable and get the success of the project.

I am curious about what would be your suggestions to include the WBS deliverable within the WBS "graphically". How do you deal with this. Any examples? Or your deliverable would be scope statement directly?

EDIT: Scope baseline = Scope statement + WBS + WBS dictionnary.

2 Answers 2


Even Agile can have some initial planning and artifacts produced. I described it here. So, it's totally ok, if your roadmap starts with "Onboarding and initial backlog creation" phase/sprint/milestone. And it is very helpful to avoid impression from your customer that you start working on features on 1st week of your project.

So, in regular PM you can also have such deliverable in your WBS, certainly. PM duties are also part of project scope.


I would say that if we keep in my that the WBS is (amongst others) a communication tool, I will at the planning deliverable leg, if this helps to manage stakeholders expectations or if it reassures them.

In any case, as PM, the planning leg is something you must do. Whether it is in your WBS or not.

However, I would use a more generic name, and I will give it a more deliverable oriented taste. Something like this:

  1. Project Management (leg)

1.1 Project Management Plan

1.2 Scope Baseline

1.3 Project Schedule

  1. Your scope (leg)

I guess that in that way, you can be clear about what you will deliver as PM.

In terms of the level of details to put in a WBS, I guess this is more an art than a science :).

In my case, to find the right level of details, I keep in mind what the team needs to know, what the stakeholders need, and how complex is the project. But always products or deliverables, never tasks. WBS = NOUNS, planning = VERBS

I am using classic project management together with scrum, so I am using GANTT charts to manage my communication with C-level, but I feed my chart with my backlog and sprint plannings boards.

I am currently working in a post about this: "How to create planning in agile projects".

I hope this helps! Cheers, Falcon

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.