Features Decomposition
Hi,
I would like to know what is the best decomposition for features:
for now on a web project we have for example a feature called "manage accounts" decomposed into several other features:
1. create accounts
2. disable accounts
3. enable accounts
4. update accounts
5. delete accounts
6. list accounts
each features consists of several user stories.
so like in my previous post, if we take "create accounts" sub-feature, it consists of:
1.1. as unknown user i want to create candidate account so that i can store my resume to apply to a job offer
1.2. as administrator i want to create consultant account so that employee can manage candidates
1.3. as consultant i want to create candidate account so that i can retype candidate resume into system
1.4. as administrator i want to create candidate account so that i can retype candidate resume into system
is it the best decomposition or is it better to say that there is 1 feature "manage accounts" and to attach to it all user stories from create account, delete accounts, and so on... ?
thx.
A,
I don't know if there is a "best" way to decompose features. In the User Story practice (which is not part of Scrum), there is a concept called "themes" that allows you to relate many stories to one or more "themes". For more on that topic, see:
http://www.scrumcrazy.com/User+Stories+-+Epics+and+Themes
I've also heard of some organizations mapping as follows:
Feature has one or more themes
Theme has one or more stories
Stories
There is no "best" way to do it, IMO. This area is something that Scrum does not really define, other than to say that all requirements are listed in the Product Backlog. You could have features, themes, stories, acceptance tests, or even bugs on a Product Backlog as a Product Backlog Item.
It would be a good idea, no matter how you decompose your features, to make sure that your product backlog items form vertical "strips" of functionality. In this way, you ensure that each PBI forms a fully-functioning aspect of functionality, from interface through whatever tiers you have, to data storage (if any).
Avoid creating "database" or "business layer" or "UI" PBIs that don't really provide much business value on their own.
Hi Jack,
"Avoid creating "database""
When you start a new project, how story will you use for this kind of task?
Thanks
Can someone provide me an example of how an epic is broken down into themes and themes into user story
Normally, a theme is a collection of similar epics, and an epic is a collection of stories that fulfill the epic requirement (Talking in terms of Jira here; my perspective - These is also a term call Initiatives which is a superset of themes)
- A theme would be - The login Module
- An epic would be - The ability of the user to:
- Register
- Login to the system
- Reset password
- Stories would be (for reset password):
- A forget password link, allowing the user to receive a reset password email to his/her registered email id
- The ability to reset password on the reset password screen triggered by clicking on the email received
- Validations
- Successful completion and database updation of the new password
This a very simple example, and there may be more or less stories here, but you get the gist.
Correction - In point 2 above, I meant "Epics would be" instead of "An Epic would be"