Forums

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+Stor...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