In an earlier blog I wrote about the beauty of a user story and how in the agile world we capture product requirements in the form of user stories.
In fact, user stories are the most atomic elements of our work breakdown structure. In terms of sizing and detail, they sit at the bottom of this list:
- Themes - Large focus areas that may be aspirational and span the entire organisation. They will contain multiple Initiatives.
- Initiatives - Large bodies of work that contain multiple Epics, and on their own have big objectives and can be broad.
- Epics - A grouping of Stories that cannot be completed in one sprint, but over several sprints.
- Stories - Short statements of requirements telling what is required from a perspective of an end user.
This structure is the typical breakdown, but it can be adapted to whatever the team sees as working optimally for them.
The reality is that many projects will only document the Epics and Stories, with the Initiatives either not being explicitly stated or documented as a business case or vision, often in a place that is never seen, slowly breaking the link between the organisation's goals and the executions of the tasks as new people get on-boarded.
This structure may not fit every project, and not every project must have this structure. It's a guide that can be adapted depending on the specifics of the project.