webframework effort estimate

Question

How do convert effort estimate say in function points to a specific web framework like django? Or is effort estimation solely dependent on the architecture of the web framework? ANy hints or guidelines would help.

EDIT would you be restrictive in thinking say, this is my framework, say django, and let me think in terms of converting my requirements into models and template.

or can i be generic in saying , these are my requirements, now these are my function points (any generic estimation technique) and can i convert this to constrains of django framework and come with effort estimate.

Answer 1

It probably depends on many factors like how familiar the team is to the web framework and web technology in general, complexity of the application, and how much it fits the web model -- Some application fit well into web model, while others don't. For example, I have attempted to convert an internal desktop utility with several grids into ASP.NET when ASP.NET just came out. All the features were ported, but I could not get the user acceptance because there were "too much clicking" compared to spreadsheet-like usability the original desktop app provided.

You may see increase in internal work due to splitting up work into (for instance) database, DAL, BLL, WS, UI, and reporting layer compared to more traditional desktop application. Another concern may be performance issues caused by network, browser, and/or centralizing computation to the server. You also might have to worry about browser compatibility.

Likely the only way to really know is to actually try doing some significant development in the framework you are interested with the team, implementing software of equal value and behavior.

Answer 2

I like the Scrum concept of velocity when going from size estimates to schedule estimates and have applied it successfully for years.

The problems, user stories or features are estimated using some size unit: lines of code, function points, story points, ideal work hours, gummibears, whatever. Let's say we are estimating the size in "points".

To go from this size estimate to a schedule estimate, you apply the velocity: how many points worth of completed functionality the team produced in a given time, say a n-week sprint (iteration) where n is e.g. in the range 1..4. So if you have a velocity of say 300 points per 2-week sprint and you have 500 points worth of user stories to implement in your backlog. Therefore you need two 2-week sprints to complete them all. But usually it is applied the other way around: given a fixed duration sprint, which stories can be implemented bringing the maximum value and which stories should be postponed.

How do you get a velocity number? At first you have to guesstimate it. But right after the first sprint you will have some historical velocity data for your team. Start basing your velocity estimates on this data instead of guessing. The less you tweak the numbers, the more accurate they will be over time.

This way problem sizing does not have to consider anything else than the problem itself. Team characteristics such as experience, jelling etc. manifest themselves in velocity.

A good refence on the topic is Mike Cohn's Agile Estimating and Planning.