Forums

By posting to our forums you are agreeing to the Forum terms of use.
Features Decomposition
Last Post 31 Jan 2013 08:31 AM by yaacov. 3 Replies.
  •  
  •  
  •  
  •  
  •  
Sort:
PrevPrev NextNext
You are not authorized to post a reply.
Author Messages
alain.roger
New Member
New Member
Posts:2
alain.roger

--
09 Dec 2012 06:42 PM
    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.
    Charles Bradley
    Basic Member
    Basic Member
    Posts:212
    Charles Bradley

    --
    09 Dec 2012 07:11 PM
    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.
    JackOLantern
    New Member
    New Member
    Posts:12
    JackOLantern

    --
    09 Dec 2012 11:10 PM
    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.
    yaacov
    New Member
    New Member
    Posts:4
    yaacov

    --
    31 Jan 2013 08:31 AM
    Hi Jack,

    "Avoid creating "database""

    When you start a new project, how story will you use for this kind of task?

    Thanks
    You are not authorized to post a reply.


    Feedback