In Agile projects, when a set of requirements are received from Clients, it may consist of (a mix of) A few needs, objectives, goals and some partial stories (even though it would have come in a structured document). Re-organizing (re-arranging) those into a requirements breakdown structure (RBS) helps ask right questions to client to come out with what they expect to achieve from a Project.
Image above depicts the Fibonacci series, which is used as one of the sizing techniques for User stories.
Agile project example RBS from an Operations perspective:
From a project/operations/IT perspective, (non-product development) I would suggest the following structure. This structure is also suitable for Program/Portfolio Management.
- Stakeholder needs (In terms of Vision, or as Epics) – Organization/Capability level
- Features (Objectives, high level goals) – System level
- Sub-features (optional, if possible to breakdown)
- User Stories(User level goals) – Business user level
- Tasks – Development team level
User Stories to Tasks breakdown is considered as WBS. User stories to Scenarios is considered as Requirements breakdown. However it may not be possible to break user stories to Scenarios for all types of projects. Projects which follow Use Cases may be able to follow this guideline more easily than others. It also depends on style used in writing user stories and acceptance criteria.
Example Epic :
As a VP-Operations, I need to reduce the travel expenses of Service Engineers by 15% by Dec’15.
Features
- Enabling Service Engineers to get access to all resources needed to fulfill customer requests from field
- Enabling Service Engineers to get expert help from field to complete requests in one visit.
- Enabling Service Engineers to plan their route by viewing service requests assigned to them from field.
- ……etc.
Sub-features (Optional)
(for access to resources)
- Provide access to customers Database for Service Engineers to check from field/site.
- Provide Video conference connectivity option for Service Engineers from field to SMEs at CoE/Factories.
- Provide online access for service Engineers to Central Enterprise Knowledge base of previous service reports, corrective actions, patches.
- ….etc.
User story
(for access to resources)
As a service Engineer, I want to access KB from field and update resolved requests with corrective actions, so that it is available for other Service Engineers from field online, helping reduce the number of trips a service Engineer makes.
Agile project example RBS from a Product Development perspective:
From a Product Development perspective, I would suggest the following structure. This structure is also suitable when there are multiple domains involved like Hardware, Software, Network…etc and new development is needed in each of the domains.
- Stakeholder needs -(Epics) – Product capability level
- Features – System level enablers, which help achieve product capability
- Sub-features (optional, if possible to breakdown)
- User Stories – Product user’s level
- Tasks – Development team level
Example Epic :
As a news reporter, I need a portable device with multimedia support so that I can capture news from field and use them in my reports.
Features
- Audio
- Video
- ……
Sub-features
(Optional) (for audio)
- Audio recording
- Audio playback
- Audio editing
- Noise cancellation
User story
(for audio editing)
As a device user, I want to edit the Audio recordings and store them, so that I can upload them to Newsroom.
User story sizing/estimation
Fibonacci series of numbers are used for User story sizing commonly, during planning poker sessions. Other techniques like sizing with T-shirt sizes (XXL, XL, L, M, S) is also in practice and is more suitable while Product owner is estimating stories on the product backlog.
Challenges in Requirements Management and maintaining breakdown structure
Epics, Features and Stories evolve gradually, as Product owner and development teams explore and discover more as sprints progress. Whenever new features or sub-features are identified either during User stories recording sessions/grooming or Sprint demos, product owner need to update the backlog and check for proper breakdown structure being followed. This means the epics and feature descriptions may change during project execution phase, but product owner needs to ensure that the overall Vision can still be met while accommodating evolution of requirements. This process provides opportunity for frequent inspection/evaluation of project and hence better chances for meeting Objectives.
Note
Note: This post was written by a guest blogger. My Capgemini colleague Vasudev S.
Image sources
- Droste Daisy: Alexandre Duret-Lutz via Wikimedia Commons | CC BY SA 2.0
Hello Really helpful article.
Sir, as an example if the client requirement is Camera then how it gets crack down till component subsystem level.
Please advice.
Hi Satish,
Thanks.
I am not an expert on Camera domain. Please get the sample provided below checked with a domain expert, in case you want to follow the requirements breakdown structure as illustrated above. I guess it may look like this…
Epic: As a Wildlife photographer, I need a Camera which can detect between humans and animals, and with motion analysis, so that it can trigger an alert on my Camera with an audio alarm, if the scene contains multiple animals moving in mass.
Features: Distinguishing between humans and animals
Motion analysis capability
Sub-features: contour following, ellipse fitting, Image extraction,…etc.
user stories –
As a wildlife photographer, I want to take pictures from —– range (infinity ?) of wildlife in natural habitat, so that it can be processed by camera for motion analysis.
As a wildlife photographer, I want camera to alert me with visual and audio, if large (quantify this) motion is detected by camera, so that I can plan to move to a safer location.