Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
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. –  GlenPeterson Oct 24 '12 at 3:51
2  
    
@MarkJ - those are great links, thanks for adding them in. –  GlenH7 Oct 24 '12 at 14:31
add comment

2 Answers

up vote 5 down vote accepted

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.

share|improve this answer
    
and if the team is inexperienced, then there isn't much point in estimating anyway, eh? –  David Kaczynski Oct 24 '12 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 Oct 24 '12 at 17:07
1  
@JeffO: agreed. You should still do it even if you're inexperienced. –  Bryan Oakley Oct 24 '12 at 18:48
add comment
> 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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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