Sizing & Estimation

[Ingudam Manoranjan]

Not sure if this will be the right forum, but couldn't figure out where to post, so posting here.

We have a product which has grown over the years. We wanted to re engineer the product again & hence need to size the product and come up with the estimation. Some of the ways I can think of are:

1) Function Point estimation - which is very well for new requirements. However, identifying all the FPs of the product will take quite an effort.

2) Lines of Code - This is something I can easily find out. But how do i estimate? Basically need a corelation of the effort with the LOC.

Thanks.

[Lasse Koskela]

I haven't used FP's myself but all those who've tried that I know of have said they wouldn't recommend it.

An estimate based on lines of code is about as accurate as asking the fortune teller.

I'd suggest generating relative, abstract estimates (you might call it "complexity" or you could call it "wazhingle points") for all functionality you want in the system and then implementing one thin slice of the system. That slice won't take an enormous time to implement and it sufficient for calibrating your relative estimates.

This approach would have the benefit of spending a relatively low effort in estimation ("This is twice as complex as that, that over there is about the same as this, ...") and you get more trustworthy estimates because they're based on history data (the slice) instead of pure speculation.

[Stan James]

I wholeheartedly agree with that approach. One thing you'll notice right off is there's not conversion formula from complexity to days or man-hours or anything like that. The first time you do it for a given team and customer and technology, there's no good guideline. If you take a few tasks early on and work them, you can start to develop that relationship. Maybe tasks with effort or complexity of 8 jelly beans take about 4 days.

If you have the luxury of a few days and dollars, get Mike Cohn's books on stories (a hip word for right-sized tasks) and estimates

Having done this re-platforming or re-engineering gig a couple times, I can point out some opportunities for horrific mistakes. View everything as freshly as possible. Don't assume everything in the current system is important or necessary or was ever a good idea. Don't duplicate the bugs Learn the idioms and capabilities of the new language or platform and be prepared for those to make some of your favorite bits of the old design unnecessary.
[ September 30, 2007: Message edited by: Stan James ]

[Ilja Preuss]

What exactly do you mean by "reengineering", and why do you want to do it?

[Ingudam Manoranjan]

Thanks Lasse Koskela & Stan James.
I agree with you with the approach. I have done this to some extent. We already have some historical data on the effort required for "simple", "medium" & "complex" use cases. Some analysis has been done to come up with the list of use cases and classified based on the complexity.

This is some sorta informed gut feeling type of estimation I had done. However, I am not very confident. So I want to verify with some other method.

Hi Ilja Preuss ,
Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.

Now I have loads of jsp & java files. I can come up with LOC per file and also come up with a a figurative complexity of each file, maybe like cyclomatic complexity [ some tools are readily available for that] and classify each file to a type complexity like again "simple", "medium", "complex".

Based on the above classification, I can put some rough figure for each type of file by doing, as Lasse Koskela was suggesting, a recoding of the file in the new architecure.

[Rajah Nagur]

Are there any plans of re-using existing code wherever applicable like - business layer, data access layer etc? This can affect your estimation

[Stan James]

Any mention of "use cases" and estimating scares. I'm not against having such documents, but from experience, they are much too large to use in estimation, work breakdown structures, assignments, tracking, etc. Misusing use cases and reusing old use cases led us directly to some of the nightmare scenarios that I hinted at above.

That's one reason I emphasized Mike Cohn's work. The finer grained your list of "things the customer wants" the better. I prodded my old team to switch from S,M,L estimates of 25-30 use cases to 1,2,4,8 estimates of 350-400 stories and it helped the team in many ways.

Follow up on some XP, Scrum or Story books to get more on how stories are used.

[Frank Martinig]

If you want to have a view on how Mike Cohns estimates with use case points, you can read his 2005 article "Estimating With Use Case Points" published by Methods & Tools

http://www.methodsandtools.com/archive/archive.php?id=25

Enjoy reading it

Franck

[Ilja Preuss]

Originally posted by Ingudam Manoranjan:
Reengineering, I am not sure will be the right word or not. Maybe it is plain refactoring. But here is the situation. The said product is in java & jsp codes and we want to do architectural changes.

OK.

The best way to do this I know is doing it while implementing new features, in very small increments.

It sounds like you want to do it at one fell swoop. Can you tell us more about the reasoning?

[Scott Ambler]

I provide some tips on estimating at http://www.ambysoft.com/essays/agileProjectPlanning.html#Estimating which you may find useful.

- Scott