Epic Breakdown Structure & Types of User Stories
Epic Breakdown Structure & Types of User Stories
By Deniz Iren
“There have been great societies that did not use the wheel, but there have been no societies that did not tell stories.” – Ursula K. LeGuin
As we are well aware, work to be done is represented by/based on Stories, in Agile Projects. Recently my team was asked to develop a WBS for an Agile project, by using a specific open source project management/issue tracking tool, for demonstrative purposes. While working on this assignment the team quickly figured out that “work” is already represented by stories, so defining a WBS may be wasted effort.
It is obvious that WBS is a key element of Project Scope Planning and a valuable practice for the team to be aware of all the things that are in the project. However, Agile approach to Project Management accepts that initial scope definitions are generally inaccurate, so recommends defining the scope at a low level of detail.
After a swift brainstorming session the team reached consensus about how to form a WBS, by utilizing the stories. Behold, the EBS (Epic Breakdown Structure).
EBS is simply the hierarchical representation of a group of Stories, which will be covered by the Project. It may not be a new concept but was enough to ignite the creativity within the team. Thus the team configured the project management/issue tracking tool to support the EBS.
In this model, Stories are described in greater detail (when needed) by Business Rules and Requirements.
Only one problem left to be solved. How do we address and display the work that is not related with a Story, such as Project Planning, Documentation, Building Infrastructure (e.g. development environment)? The answer is, we don’t. If a work item is present yet there is no Story defined for that purpose, just define the Story. And a really important point: Stories are not always business focused.
There are many types of Stories, described in the Agile literature. Here are a few:
- Business Story
Business focused. Almost always written by the business. Sometimes written by the analysts.
Ex: ”Student selects courses she wishes to take, from the list of all courses offered in that semester.”
-
Non Functional (Performance) Stories
Not related to the functionality of the system, but describes the performance attributes of the system, such as, Scalability, Availability, Reliability, Maintainability, Usability…
Ex: “Registration pages use the same font and background color scheme as the other pages of the Student Affairs Information System.”
Ex: ”The Student Affairs Information System is up and running 99.9% during the registration time period defined in the Academic Calendar.”
-
Documentation Stories
Even Agile projects need documentation and keeping documentation requires effort.
Ex: “The user manual of registration program is written in both English and Turkish, describing the registration procedure and providing screenshots.”
-
Defect/Bug Stories
Stories defining how/what to fix some buggy functionality which were delivered in an earlier iteration.
Ex: “Warning message displayed is translated to Turkish from Mandarin Chinese when Advisor approves Student’s Course List.”
-
Spike Stories / Technology Debt
There are times when the team is not familiar with a new technology or approach which may be used in upcoming iterations. Or we simply think that spending effort on a utilization of a tool/technique will save time and effort in the future. So we carry out our own personal R&D for a bit of time. This should be defined by a Spike Story, aka Technology Debt.
Ex: “Voice operated semantic search utility of Mikrokom Corp. is examined.”
-
Plannning / Estimating Stories
The team spends time when planning the project. Define this time by a Planning Story.
Ex: “The planning game takes place.”
-
Meeting Stories
Many governmental organizations never miss the opportunity to socialize, so they organize meetings… lots and lots of meetings…
Just write a story for upcoming meetings.
Ex: “Progress and risk review meeting is organized.”
-
Architecture / Infrastructure Stories
All projects need infrastructure support to some extent. Show the effort spent in establishing the infrastructure as an Infrastructure Story.
Ex: “Redmine the Issue Tracking Tool is deployed and user authentication mechanisms for the software support team members are developed.”
© Deniz Iren, PMP. You can read more from Deniz on his blog.
