Can you use a WBS in agile projects?

Some may have the perception that a WBS is a tool solely used in more traditional waterfall type of projects, but that is not the case! It is definitely as useful in agile projects, but there are a couple of considerations that you need to be aware of. A WBS should represent the work in the project, and the backlog used in agile projects is actually a kind of implicit WBS.

Typically larger epics or features (depending on agile framework being used) are broken down as they are about to be developed or explored further.

Typically in agile, user stories, the broken down parts of a larger epic or feature, is then replacing their parent, and in that way, the relationship between user stories are then lost, and the big picture can get lost.

There are agile ways of managing user stories that tries to circumvent this problem, like story mapping, which tracks both the parent feature in a kind of “value chain”, as well as the iteration that user stories will be delivered for the specific feature. In that way, the hierarchy is kept intact, enabling various time horizons to be planned on a holistic level, while ensuring enough detail for the near term.

A proper WBS tool, such as breakdownstructure.com, enables users to work with agile backlogs, keeping an ordered list of features, while still retaining the hierarchical relationships of the features. If the tool supports tags, it also allows the user to work with story mapping. Breakdownstructure.com not only allows for tags, but also integrates with Trello to enable teams to do the overall planning in Breakdown Structure, while the teams can focus on the details in Trello.

So how should you structure your WBS in agile? That will be the topic for an upcoming blog post here. Stay tuned.