Using Completed User Stories to Estimate Future User Stories

Question

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?

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 03:51
http://programmers.stackexchange.com/questions/39386/how-to-estimate-the-length-of-a-programming-task, http://programmers.stackexchange.com/questions/648/how-to-respond-when-you-are-asked-for-an-estimate — MarkJ, Oct 24 '12 at 11:36

score 5 · Accepted Answer · answered Oct 24 '12 at 01:14

5

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.

answered Oct 24 '12 at 01:14

Bryan Oakley

25,192
5
64
89

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

score 0 · Answer 2 · answered Oct 24 '12 at 11:17

> 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

Using Completed User Stories to Estimate Future User Stories

2 Answers2