Search code examples
project-managementproject-planningestimationweb-frameworks

webframework effort estimate


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.


Solution

  • 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.