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, we are proposing a 4 tier structure:

Level 1:

We can call this Feature or Module.

Level 2:

Our good old friend - Epic

Level 3:

Our perennial favorite User stories

Level 4:

Acceptance and Done criteria

Feature and Epic could spread over sprints whereas user stories and acceptance criteria should be completed in one sprint.