In Scrum/Agile, the complexity of a user story can be estimated in story points. After completing some user stories, a programmer or team of programmers can use those experiences to better estimate how much time it might take to complete a future user story.

Is there a methodology for breaking down the complexity of user stories into quantifiable or quantifiable attributes?

For example, User Story X requires a rich, new view in the GUI, but User Story X can perform most of its functionality using existing business logic on the server. On a scale of 1 to 10, User Story X has a complexity of 7 on the client and a complexity of 2 on the server. After User Story X is completed, someone asks how long would it take to complete User Story Y, which has a complexity of 3 on the client and 6 on the server. Looking at how long it took to complete User Story X, we can make an educated estimate on how long it might take to complete User Story Y.

I can imagine some other details:

  • The complexity of one attribute (such as complexity of client) could have sub-attributes, such as number of steps in a sequence, function points, etc.
  • Several other attributes that could be considered as well, such as the programmer's familiarity with the system or the number of components/interfaces involved
  • These attributes could be accumulated into some sort of user story checklist.

To reiterate: is there an existing methodology for decomposing the complexity of a user story into complexity of attributes/sub-attributes, or is using completed user stories as indicators in estimating future user stories more of an informal process?

  • 1
    It's so hard to truly understand what the user needs... If the developer and business analyst have both done significant tech support for a mature product, maybe you can start asking questions like this. Otherwise, I'd focus on getting the RIGHT story rather than worrying about analyzing how complex it is. That said, you may have some data that gives you a multiplcation factor or exponent for comparing server-side complexity vs. client side FOR YOUR APPLICATION. E.g. server changes might be twice as complicated on average, or an order of magnitude more complicated. Commented Oct 24, 2012 at 3:51
  • 2
  • @MarkJ - those are great links, thanks for adding them in.
    – user53019
    Commented Oct 24, 2012 at 14:31

2 Answers 2


In my experience it is very informal. If the team is fairly experienced they should be able to look at a story and decide if it's going to require about the same effort as another story, or considerably more, or considerably less. Story points are only approximate, so accuracy isn't much of a concern as long as you apply your judgement somewhat consistently.

  • and if the team is inexperienced, then there isn't much point in estimating anyway, eh? Commented Oct 24, 2012 at 15:08
  • 1
    Inexperienced programmers should still attempt to estimate for practice and to use as a benchmark for improvement. Don't rely on your memory alone.
    – JeffO
    Commented Oct 24, 2012 at 17:07
  • 1
    @JeffO: agreed. You should still do it even if you're inexperienced. Commented Oct 24, 2012 at 18:48
> use (those) experiences to better estimate how much time 
> it might take to complete a future user story.

The Function_point_analysis fpa is not based on userstories but it might be helpful to estimate once there is enough experinence.

The "attributes" or dimensons of fpa are outputs, inquiries, inputs, internal files, and external interfaces

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.