There is a misconception out there that if you use an Agile project management method like Scrum to manage your projects, you can’t use Work Breakdown Structure or WBS for short.
There’s too much confusion, a project manager gets no relief (I am borrowing from my favorite poet Bob Dylan here).
There are those who swear by the Agile method and then there are those who think Agile is a waste of time and does not work.
The argument against WBS by those who practice Agile is that at the beginning of a project, the scope of the work is not known.
They also note, during the project’s lifecycle, the requirements often change, the market changes, and the competition will not sit idle and surprises you.
So according to Agile practitioners, spending time on WBS at the beginning of the project is useless and a waste of time for any Agile project.
This assumption is wrong. Too bad since the Agile projects will miss out on the huge benefits which WBS offers in Agile environments. The WBS Agile combo (now called Hybrid project management, also read Hybrid manifesto ) can help projects that don’t fit perfectly in either WBS or Agile methods.
Let me state this again, the Agile project method benefits greatly when using the work breakdown structure for managing tasks and milestones in projects.
To take on Pure Agile advocates heads on, let me set the record straight.
You can and should use WBS not just at the beginning of a project, but at the start of each sprint in the project. I call it the Agile Work breakdown structure or AWBS.
Work breakdown structure is the method used to simplify complex tasks by breaking down each task into many smaller tasks called subtasks.
The resulting subtasks are broken down further into yet smaller subtasks.
This process continues until the subtasks are well defined and small enough in size and scope that could start and finish in a few days or a couple of weeks at most.
The resulting subtasks only take a short time to work on and complete because they are well understood and defined well.
Not simplifying complex tasks to their smaller components is a recipe for project delay and even failure.
The benefits of the work breakdown structure are well documented and can benefit Agile methods greatly.
After all, a task is a task regardless if it is done in projects using the traditional methods or Agile methods.
The simpler and more defined a task, it is easier to estimate the time it takes to complete it and the better accuracy of estimation.
It also makes it easier to assign small tasks to the right resource. Resource planning a huge problem when task estimation is difficult to impossible.
Many experienced project managers use WBS to get a handle on complex and large projects.
[clickToTweet tweet=”The benefits of work breakdown structure are well documented. Many experienced project managers use WBS to get a handle on very complex and large projects.” quote=”Combining Agile and work breakdown structure creates the best project management method to plan, track, and manage complex projects.” theme=”style3″]
Work breakdown structure in Agile
The benefits of the Agile method are well known.
The fact that projects in Agile are broken down into small time slices called sprints make Agile and WBS natural partners for the best results. I call this Agile WBS combination AWBS.
I believe, WBS is instrumental in helping the Agile method to become a better project management methodology and get wider acceptance in the project management community.
The biggest complaint about the Agile method is the lacking of certainty as to when the project will finish.
The lean approach which both Agile and WBS are based on can help manage projects using the Agile method more predictable, manageable, and reliable.
When managing a project using the Agile method, use the WBS method to break down tasks found in the backlog before moving them to the next sprint.
This way, tasks that are worked on in each sprint are well defined and small enough so that they could have a better chance of completing on time in 2 to 4 weeks or less.
In my work, I have used the work breakdown structure in Agile in many projects in the past few years. The results have been anything but amazing.
What is surprising, this combined method works well for small and large projects. It even works better when the project involves multiple technical disciplines.
Not surprisingly, the projects which have some research in them and all work is not known at the start of the project, benefit most from using the combination of WBS and the Agile method.
So how Binfire can help you use both Agile and WBS, you might ask? How you can use WBS in Agile?
Binfire’s task manager is based on the work breakdown structure and gives you the ability to create sub-tasks 6 levels deep.
This is complete enough for even the most complex projects as recommended by the Project Management Institute or PMI for short.
Each project also has a Kanban board and a dashboard that allows work in an Agile environment.
In addition to each project having its own Kanban board, there is a portfolio Kanban board that shows tasks from all your projects.
This is a huge benefit to the program manager since all projects are shown on one page and any delay in one task from project A which will affect issues on tasks in project B can easily be identified.
The user can create and manage unlimited Kanban boards.
The Kanban board is the preferred tool for the Agile project management method.
One of the lists on the Kanban board is the backlog list.
As a side note in the new Binfire, you can create your own Kanban board any way you like. There is no limit to the number of Kanban boards you can create for each project or the project portfolio as a who.
You can add all the tasks in the project to the backlog list at the start of the project.
At the start of each sprint, move tasks you want from the backlog to the “To-Do Task” list by using drag and drop.
A great feature in Binfire which helps to manage Agile projects easier is the ability to copy or move tasks from one project to another project.
This helps to keep tasks in the backlog list in one project and move them to new projects (or sprint) as they are needed.
Another feature lets you use one project that you have already populated and worked on as a template for your new projects.
All tasks, members, and the other information you have in the original project are copied to the new project.
The start and end dates of the project and tasks are adjusted to reflect a new start date.
These features make it much easier and save time when managing multiple projects using Agile methods.
To understand how work breakdown structure works, read the WBS tutorial we recently published in Collaboration Corner.
A new project management concept called Hybrid project management which combines Agile and Work Breakdown structure is gaining wide acceptance.
Hybrid creates a potent new project management method which is based on the combination of Agile and WBS as we cover in this paper.
Hybrid is one of the hottest new trends in project management and gaining momentum among project managers.
If you are not familiar with Hybrid, give it a try. It helps to ease the introduction of the Agie method to teams that have used in the past traditional project management methods.
Try Binfire for free and see how it can help you manage your Agile projects better.
"This way you have all tasks defined for the project in the backlog and for each sprint you move a small subset to sprint 1, sprint 2 and so on"
David,
There is one of two things happening here. Either you are using task to mean something different than that used in agile planning or you're fundamentally misunderstanding how the incremental and iterative planning works for agile teams.
tasks are generally the smaller units of work done by teams that add up to user stories. Tasks represent effort while stories are user visible value. So large stories do get broken down into smaller stories and stories can eventually be broken down into tasks, but this happens throughout the entirely lifestyle of a project not up front. And task breakdowns occur inside the team as they are preparing to start working on a story.
Was this your intention in describing how your tool would work in an agile context? Or we're you envisioning a PM doing this work at the start of a project? From your article it was nt clear.
–bab
Hi Brian,
Thank you for the comment. You are right, I was not clear enough in the post. I don't mean the PM doing all this work at the start, since it is not efficient and defeats the concept of incremental work.
We use task containers (tasks which have sub-tasks and sub sub-tasks etc) for user stories. At each sprint we move some of the tasks from the user story to the sprint or the whole container task (user story) depending if it can be done in the time frame we use.
Regards,
David
"This way you have all tasks defined for the project in the backlog and for each sprint you move a small subset to sprint 1, sprint 2 and so on"
David,
There is one of two things happening here. Either you are using task to mean something different than that used in agile planning or you're fundamentally misunderstanding how the incremental and iterative planning works for agile teams.
tasks are generally the smaller units of work done by teams that add up to user stories. Tasks represent effort while stories are user visible value. So large stories do get broken down into smaller stories and stories can eventually be broken down into tasks, but this happens throughout the entirely lifestyle of a project not up front. And task breakdowns occur inside the team as they are preparing to start working on a story.
Was this your intention in describing how your tool would work in an agile context? Or we're you envisioning a PM doing this work at the start of a project? From your article it was nt clear.
–bab
Hi Brian,
Thank you for the comment. You are right, I was not clear enough in the post. I don't mean the PM doing all this work at the start, since it is not efficient and defeats the concept of incremental work.
We use task containers (tasks which have sub-tasks and sub sub-tasks etc) for user stories. At each sprint we move some of the tasks from the user story to the sprint or the whole container task (user story) depending if it can be done in the time frame we use.
Regards,
David
"This way you have all tasks defined for the project in the backlog and for each sprint you move a small subset to sprint 1, sprint 2 and so on"
David,
There is one of two things happening here. Either you are using task to mean something different than that used in agile planning or you're fundamentally misunderstanding how the incremental and iterative planning works for agile teams.
tasks are generally the smaller units of work done by teams that add up to user stories. Tasks represent effort while stories are user visible value. So large stories do get broken down into smaller stories and stories can eventually be broken down into tasks, but this happens throughout the entirely lifestyle of a project not up front. And task breakdowns occur inside the team as they are preparing to start working on a story.
Was this your intention in describing how your tool would work in an agile context? Or we're you envisioning a PM doing this work at the start of a project? From your article it was nt clear.
–bab
Hi Brian,
Thank you for the comment. You are right, I was not clear enough in the post. I don't mean the PM doing all this work at the start, since it is not efficient and defeats the concept of incremental work.
We use task containers (tasks which have sub-tasks and sub sub-tasks etc) for user stories. At each sprint we move some of the tasks from the user story to the sprint or the whole container task (user story) depending if it can be done in the time frame we use.
Regards,
David
"This way you have all tasks defined for the project in the backlog and for each sprint you move a small subset to sprint 1, sprint 2 and so on"
David,
There is one of two things happening here. Either you are using task to mean something different than that used in agile planning or you're fundamentally misunderstanding how the incremental and iterative planning works for agile teams.
tasks are generally the smaller units of work done by teams that add up to user stories. Tasks represent effort while stories are user visible value. So large stories do get broken down into smaller stories and stories can eventually be broken down into tasks, but this happens throughout the entirely lifestyle of a project not up front. And task breakdowns occur inside the team as they are preparing to start working on a story.
Was this your intention in describing how your tool would work in an agile context? Or we're you envisioning a PM doing this work at the start of a project? From your article it was nt clear.
–bab
Hi Brian,
Thank you for the comment. You are right, I was not clear enough in the post. I don't mean the PM doing all this work at the start, since it is not efficient and defeats the concept of incremental work.
We use task containers (tasks which have sub-tasks and sub sub-tasks etc) for user stories. At each sprint we move some of the tasks from the user story to the sprint or the whole container task (user story) depending if it can be done in the time frame we use.
Regards,
David
"This way you have all tasks defined for the project in the backlog and for each sprint you move a small subset to sprint 1, sprint 2 and so on"
David,
There is one of two things happening here. Either you are using task to mean something different than that used in agile planning or you're fundamentally misunderstanding how the incremental and iterative planning works for agile teams.
tasks are generally the smaller units of work done by teams that add up to user stories. Tasks represent effort while stories are user visible value. So large stories do get broken down into smaller stories and stories can eventually be broken down into tasks, but this happens throughout the entirely lifestyle of a project not up front. And task breakdowns occur inside the team as they are preparing to start working on a story.
Was this your intention in describing how your tool would work in an agile context? Or we're you envisioning a PM doing this work at the start of a project? From your article it was nt clear.
–bab
Hi Brian,
Thank you for the comment. You are right, I was not clear enough in the post. I don't mean the PM doing all this work at the start, since it is not efficient and defeats the concept of incremental work.
We use task containers (tasks which have sub-tasks and sub sub-tasks etc) for user stories. At each sprint we move some of the tasks from the user story to the sprint or the whole container task (user story) depending if it can be done in the time frame we use.
Regards,
David