This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have read some articles on Function point analysis and combining it with use cases, mainly from www.softwaremetrics.com. After detailing the use cases, we count the number of function points in that use case and use that for estimation. With this we can come up with the size of the software, but when it comes to effort, there are other activities which may be related or unrelated like team meetings, deployment etc. How do we account for all those? Is there any standard way of doing it?
I haven't really studied function point analysis (I know what it is, but don't know how to actually do it), but XP handles estimation empirically based on the previous iteration's actuals. For the first iteration, when there's no history to build on, some folks estimate in ideal engineering time and multiply the estimate by 3 to get the calendar time. Maybe you should try something like that -- throwing your best guess and then narrowing down when you start getting data about how accurate your guesstimate was.
We are able to evaluate a use case catalog (names and brief descriptions, not complete docs) as small, medium, large or jumbo and apply some spreadsheet calculations to come up with a volume of work. We also happen to know how fast we turn out work and can get a ballpark guess on how long it will take. We tell people it is plus or minus 50 percent, which is a huge variance, but it's actually close enough for us to know whether or not to sign up for a job. Of course we have the advantage of roughly the same team in roughly the same business domain for about 8 years now, so we apply a lot of experience to the calculations. I'd be lost trying to do this from scratch for a new team. The next step is the really good one. We spend a day or two with the customer and lay out a list of stories. These average out to be about the size of a use case flow. So a use case with several flows would generate several stories. Developers go through the stories and estimate them in story points. These are not days but some abstract estimate of work. The important thing is that 4 is twice as much work as 2, and 8 is twice as much as 4. Then we match up to the first estimate. Maybe it said we need 200 days, ten four-week iterations. We have 40000 points. Can we do 200 points in an iteration? Again we have some experience that helps us say yes or no. Even without the experience, you get some feeling of whether the first estimate was any good. Now we start working. At the end of each four-week iteration we see how many points we REALLY did. 175? The whole schedule may be in trouble. 215? Probably good with a little room for story growth from defects and missed stories. Now you watch each iteration very closely and learn your real velocity in points/iteration. You can't do much to force velocity to improve, so don't fool yourself. The advantage to all this is that it's very visible and very honest. Everybody can see your chances of making the estimated finish and nobody can spin the results. We found this openness and honesty made the customer much more accepting when we discovered the original estimate was bad and delivery would be a couple iterations later. They just said, yes, I see, I understand, we can wait that much longer for the right product. Any of that help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Just one thing to add: The best strategy to reduce risk with hard to estimate activities such as deployment is to start them early. That is, make deploying an every day activity. Deploy a running system from the first day on instead of waiting for the latest possible moment. (Deployment on the first day will be really simple, of course.) There are several advantages if you do this: - you won't get surprised by basic deployment problems late in the project - the schedule gets much more predictable - you will get really good at deployment - especially, you will need to automate most (if not all) of it to even be able to do it daily (which is a good thing) - you always have a running test system
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus