Structuring requirements in agile projects
All agile enthusiasts swear by user stories as user stories are succinct, are told from a user’s perspective, contain the user expectation from the system and contain the value the requirement provides.
However, even for a small size project, the number of user stories can sometimes be quite large.
In a recent project, I worked with about 10 members for 3 months, and we had more than 300 user stories developed.
Most agile books suggest a 2 tier structure for managing agile requirements – namely, Epics and Stories.
But, will this be good enough for a slightly larger project where the user stories can easily cross 1000?
For such big projects with a large number of user stories, I am proposing a 4 tier structure:
We can call this Feature or Module.
Our good old friend – Epic
Our perennial favorite User stories
Acceptance and Done criteria
Feature and Epic could spread over sprints whereas user stories and acceptance criteria should be completed in one sprint.
I am a professional BA practitioner, trainer, coach, and author with AdaptiveUS, a leading business analysis solutions (training, consulting and product) organization.
If you like my posts please like/share/comment and spread the word in your network.
You can reach me at LN@adaptiveus.com.
About Adaptive US (Think BA. Think Adaptive.)
Adaptive US provides CBAP, CCBA, ECBA and other business analysis certification training online and consulting needs for Individual or Corporate either online or offline. Adaptive US is an endorsed education provider of IIBA®