Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What should be the main point to keep in mind when estimating the time for Research and Development task. Suppose I have to estimate "ABC" task using "WPF" technology and I have no experience for it, I need to some R&D for it.
Don't give an estimate until you have had time to play with the technology. Allocate a certain time (2 days, 1 week, whatever you can get from management) to understand the concepts and write some code yourself with it, to get a sense for what the development process takes and how steep the learning curve is. Then, estimate.
Pure Research Projects
Set a time or resource cap in addition to a number of interim milestones / reviews, to re-evaluate whether you can afford to continue. Ideally before embarking on the research you will have a good idea of potential benefits of succeeding. You might also want to define different grades of success and a contigency plan in case the effort will not come to fruition, before you start.
Spiral model of development will come handy.
Applying Existing Technology to a Problem
For current mainstream technologies such as WPF you might try to find out how long would it take for someone with comparable experience to learn the technology. Evidence might be collected from other people experience and available training courses.
For non-current or niche technologies you might be better off hiring a consultant or sub-contracting the job (bear in mind the difference between consultant and contractor).
Grade the project on
Keeping Status Quo - Bug Fixing - Enhancement - New Functionality - New Product - Revolutionary
scale. Each position on the scale will usually mean a factor of 2..5 of risk and effort increase. Having a reference point which is to say if it normally takes 2 days in your organisation end-to-end to fix a bug, you can gauge that an enhancement will take two to five times longer, anything between 4 to 10 days, of course coding will only be a small proportion of the this effort.
Ideally, one should not give an estimate without solid evidence. After all, an estimate is a probability, and probabilities are mathematically significant figures, not gut feelings pulled off thin air. (See "Software Estimation" by Steve McConnell for more on this.)
Unfortunately, too often we are required to provide estimates on tasks for which we have a great deal of uncertainty about the technologies that will be involved. This is the case, for example, of government grants and other non-technical scenarios. In these cases, and being pragmatic, it is good to provide an estimate even when we are not familiar with the technologies.
Techniques that I often use include uncertainty cones and timeboxed development.
Hope this helps.
The best way to approach it is consult with someone who has been there already.
His experience plus general idea of of good he is compare to your staff should give you a fair estimation.
The older the technology is - the more experienced people there will be around and more places on the web to find answer to question.
If you're researching something brand new... the data sources should be limited and I will take any estimation, and double it....
You could take a guess as to how long you think it'll take you to research the new technology and then how long it'll take for you to do the development and multiply that by two. Of course that's pretty fluffy, but usually anything involving estimating a task is pretty fluffy (well, at least I don't like to). There are so many factors involved when estimating: whether it be dealing with new technologies that could be take longer than you think, usually it involves dealing with code written by other people which could add an 'x' factor of complexity to what should be a simple task.
Usually when estimating time, it's always best to at least have a general 'spike' where you sit (whether it be by yourself, or even better with some other team member) and have a play for an hour or two (or however long you choose). This at least gives you a bit of time to have better context with what you're dealing with. When looking at the new technology, perhaps read a bit of the doco, read and play with a 'getting started' guide etc. Then when you go back to the estimation table, you will have a better idea with what you're dealing with.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As a lead developer I often get handed specifications for a new project, and get asked how long it'll take to complete the programming side of the work involved, in terms of hours.
I was just wondering how other developers calculate these times accurately?
Thanks!
Oh and I hope this isn't considered as a argumentitive question, I'm just interested in finding the best technique!
Estimation is often considered a black art, but it's actually much more manageable than people think.
At Inntec, we do contract software development, most if which involves working against a fixed cost. If our estimates were constantly way off, we would be out of business in no time.
But we've been in business for 15 years and we're profitable, so clearly this whole estimation thing is solvable.
Getting Started
Most people who insist that estimation is impossible are making wild guesses. That can work sporadically for the smallest projects, but it definitely does not scale. To get consistent accuracy, you need a systematic approach.
Years ago, my mentor told me what worked for him. It's a lot like Joel Spolsky's old estimation method, which you can read about here: Joel on Estimation. This is a simple, low-tech approach, and it works great for small teams. It may break down or require modification for larger teams, where communication and process overhead start to take up a significant percent of each developer's time.
In a nutshell, I use a spreadsheet to break the project down into small (less than 8 hour) chunks, taking into account everything from testing to communication to documentation. At the end I add in a 20% multiplier for unexpected items and bugs (which we have to fix for free for 30 days).
It is very hard to hold someone to an estimate that they had no part in devising. Some people like to have the whole team estimate each item and go with the highest number. I would say that at the very least, you should make pessimistic estimates and give your team a chance to speak up if they think you're off.
Learning and Improving
You need feedback to improve. That means tracking the actual hours you spend so that you can make a comparison and tune your estimation sense.
Right now at Inntec, before we start work on a big project, the spreadsheet line items become sticky notes on our kanban board, and the project manager tracks progress on them every day. Any time we go over or have an item we didn't consider, that goes up as a tiny red sticky, and it also goes into our burn-down report. Those two tools together provide invaluable feedback to the whole team.
Here's a pic of a typical kanban board, about halfway through a small project.
You might not be able to read the column headers, but they say Backlog, Brian, Keith, and Done. The backlog is broken down by groups (admin area, etc), and the developers have a column that shows the item(s) they're working on.
If you could look closely, all those notes have the estimated number of hours on them, and the ones in my column, if you were to add them up, should equal around 8, since that's how many hours are in my work day. It's unusual to have four in one day. Keith's column is empty, so he was probably out on this day.
If you have no idea what I'm talking about re: stand-up meetings, scrum, burn-down reports, etc then take a look at the scrum methodology. We don't follow it to the letter, but it has some great ideas not only for doing estimations, but for learning how to predict when your project will ship as new work is added and estimates are missed or met or exceeded (it does happen). You can look at this awesome tool called a burn-down report and say: we can indeed ship in one month, and let's look at our burn-down report to decide which features we're cutting.
FogBugz has something called Evidence-Based Scheduling which might be an easier, more automated way of getting the benefits I described above. Right now I am trying it out on a small project that starts in a few weeks. It has a built-in burn down report and it adapts to your scheduling inaccuracies, so that could be quite powerful.
Update: Just a quick note. A few years have passed, but so far I think everything in this post still holds up today. I updated it to use the word kanban, since the image above is actually a kanban board.
There is no general technique. You will have to rely on your (and your developers') experience. You will have to take into account all the environment and development process variables as well. And even if cope with this, there is a big chance you will miss something out.
I do not see any point in estimating the programming times only. The development process is so interconnected, that estimation of one side of it along won't produce any valuable result. The whole thing should be estimated, including programming, testing, deploying, developing architecture, writing doc (tech docs and user manual), creating and managing tickets in an issue tracker, meetings, vacations, sick leaves (sometime it is batter to wait for the guy, then assigning task to another one), planning sessions, coffee breaks.
Here is an example: it takes only 3 minutes for the egg to become roasted once you drop it on the frying pen. But if you say that it takes 3 minutes to make a fried egg, you are wrong. You missed out:
taking the frying pen (do you have one ready? Do you have to go and by one? Do you have to wait in the queue for this frying pen?)
making the fire (do you have an oven? will you have to get logs to build a fireplace?)
getting the oil (have any? have to buy some?)
getting an egg
frying it
serving it to the plate (have any ready? clean? wash it? buy it? wait for the dishwasher to finish?)
cleaning up after cooking (you won't the dirty frying pen, will you?)
Here is a good starting book on project estimation:
http://www.amazon.com/Software-Estimation-Demystifying-Practices-Microsoft/dp/0735605351
It has a good description on several estimation techniques. It get get you up in couple of hours of reading.
Good estimation comes with experience, or sometimes not at all.
At my current job, my 2 co-workers (that apparently had a lot more experience than me) usually underestimated times by 8 (yes, EIGHT) times. I, OTOH, have only once in the last 18 months gone over an original estimate.
Why does it happen? Neither of them, appeared to not actually know what they are doing, codewise, so they were literally thumb sucking.
Bottom line:
Never underestimate, it is much safer to overestimate. Given the latter you can always 'speed up' development, if needed. If you are already on a tight time-line, there is not much you can do.
If you're using FogBugz, then its Evidence Based Scheduling makes estimating a completion date very easy.
You may not be, but perhaps you could apply the principles of EBS to come up with an estimation.
This is probably one of the big misteries in the IT business. Countless failed software projects have shown that there is no perfect solution to this yet, but the closest thing to solving this I have found so far is to use the adaptive estimation mechanism built in to FogBugz.
Basically you are breaking your milestones into small tasks and guess how long it will take you to complete them. No task should be longer than about 8 hours. Then you enter all these tasks as planned features into Fogbugz. When completing the tasks, you track your time with FogBugz.
Fogbugz then evaluates your past estimates and actual time comsumption and uses that information to predict a window (with probabilities) in which you will have fulfilled your next few milestones.
Overestimation is rather better than underestimation. That's because we don't know the "unknown" and (in most cases) specifications do change during the software development lifecycle.
In my experience, we use iterative steps (just like in Agile Methodologies) to determine our timeline. We break down projects into components and overestimate on those components. The sum of these estimations used and add extra time for regression testing and deployment, and all the good work....
I think that you have to go back from your past projects, and learn from those mistakes to see how you can estimate wisely.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
We are a small team (3 developers) and one of our main clients is about to submit a bunch of new feature requests and a follow on project to us to get estimates on cost and delivery times. Our last project with them was a 'success' in that they are coming back to us but I know we could have done a much better job (we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem).
I have just finished reading 'Art of Unit Testing' and 'Working Effectively with Legacy Code' and I have used TDD on a pet project of mine outside of work and now I can never go back to waterfall and testing after the fact.
What I want to know is are there are good 'easy to digest' videos for non-developers that clearly show the benefits of TDD along with Agile practices in a business sense? I'd be super happy if there are any sub 10 minutes videos but I'm also OK with longer videos (and I will reference them to a time index in it). If there are no good videos then a written source is next best thing.
I want nothing more than for them to be on board and really excited with the transition.
For me it is not an option to 'just do it' as there will definitely be a learning curve for the other two developers and without doubt the first number of iterations may be stressful and bumpy and that needs to be communicated to our client.
[I have answered my own question below with a number of videos I found since asking the question... they are not perfect for my use but definately my plan B if no-one else knows of a better one]
Technical debt kills velocity. Thus, I like to include "No increased technical debt" in the Definition of Done. Without this, you can't achieve sustainable pace. This is illustrated by the picture below (borrowed from the Technical Debt - How not to ignore it presentation from Henrik Kniberg):
alt text http://img27.imageshack.us/img27/329/screenshotkq.png
To me, all these things are obvious and you can even prove it with numbers (by measuring the velocity over time). Explain these concepts to your client, explain him that TDD is one of the techniques allowing to control technical debt. Then, let him choose (or choose for him).
How you run your project internally is your business. Don't involve them in this decision. They are not experts in software development processes. Ask them about business requirements and things they know about.
Sound like you are doing this to improve project quality. Do you think it will cost more to do TDD? Why work to convince them of something and then ask their approval? Did you ask if you could do waterfall on the last project?
Why would your client even notice the transition to TDD? Stressful, bumpy; how so?
Tell the client why you are upgrading to TDD. I'm sure the reasons are as compelling to them as they are to you. To me, TDD first of all means a much greater sense of reliability on what you produce.
Surely your client remembers all the regressions and manual testing from your last project?
I don't know of any specific illustrations for you (the web is full of articles and blogs, but I'm not aware of any videos), but you pretty much answered your own question...
we used waterfall... testing was an after thought and as a result unit-testing code coverage is significantly lower than we feel comfortable with, not to mention the never-ending 'we are ALMOST done' problem
You just need to be honest with your client. Explain to them what the project methodology you used on your last project cost them in terms of flexibility, maintainability, and your ability to confidently provide them with quality code. Explain to them how TDD addresses that, and explain that you anticipate a slower start due to using a new methodology.
Illustrate for them, as concretely as possible, what they will gain, and it should be an easy sell. I would, however, approach it more from the "this is what we're planning on doing" angle, rather than the "can we please do this?" angle. Give them the impression (without being dishonest) that you are already planning on going this way and any change to that plan will be an inconvenience to you and your team, and will likely cost them productivity.
I'm not aware of any videos, but explain to them that it took you N man-hours to redesign a certain feature on the last project due to original design not being correct taht was not caught until you started testing; and with TDD it would take M (<<N) man-hours since you would not spend the extra hours working based on a bad design/bug as happened last time.
Also, explain that the confidence level of having less buggy software will be raised by Y percent due to thought-out tests.
Then explain you estimate X hours for learning curve on the FIRST peoject, and ask them if the given benefits on ALL future projects will be worth it, when the initial time investment is depreciated across those.
Firstly, unit testing isn't unique to Agile methodologies; I've been around a while and have seen it used on waterfall projects. In fact, I heard of unit testing long before I heard of Agile!
Afraid I can't point you to any videos that will help convince a client to switch development methodologies. Google may help though; if not with videos, then maybe with studies, blogs, etc.
Anyway, one suggestion for improving the chances that the client will accept your reduced productivity during your learning curve is to reduce his costs somehow. E.g. if you're billing by the hour either charge less by the hour for time spent learning, or just don't bill for those learning hours.
I spent the time since asking this question looking for the best videos I could and I've come across a number that are very close to what I need. I will post them here so that others will find them if they are in a similar position to me.
I realise that I asked more about TDD - but these videos capture a good portion of the message I'm trying to drive home... especially 'Why does Agile Software Development Pay' and 'Scrum in under 10 minutes'... it is the process of being responsive to change, producing higher quality code, having fewer defects and faster development cycles.
Agile vs waterfall: A Tale of Two Teams (8:20)
Why does Agile Software Development Pay? (5:03)
Scrum Basics (5:50)
Scrum in under 10 minutes (7:59)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I lead a small group of programmers in a university setting, having just moved into this position last year. While the majority of our team are full time employees, we have a couple of people who are traditionally graduate assistants.
The competition for these assistantships is fairly intense, as they get free graduate school tuition on top of their salary while they have the job. We require that they sign up for at least a year, though we consider ourselves lucky if they stay for two. After that, they get their master's degree and move on to bigger and better things.
As you can imagine, hiring and re-training these positions is time- and resource-intensive. To make matters worse, up to now they have typically been the sole developer working on their respective projects, with me acting in an advisory and supervisory role, so wrangling the projects themselves to fight the entropy as we switch from developer to developer is a task unto itself.
I'm tempted to bring up to the administrators the possibility of hiring a full- (and long-haul) developer to replace these two positions, but for a school in a budget crisis, paying for two half-time graduate assistants is far cheaper (in terms of salary and benefits) than paying for one full-time developer. Also, since I'm new to this position, I'd like to avoid seeming as though I'm not able to deal with what I signed up for. For the forseeable future, I don't think the practice of hiring short-term graduate assistants is going to change.
My question: What can I do to create an effective training program considering that the employees may be gone after as little as a year on the job?
How much time should I invest in training them, and how much would simply be a waste of time?
How much time should they take simply getting acclamated to our process and the project?
Are there any specific training practices or techniques that can help with this kind of situation?
Has anyone dealt with a similar situation before?
Do I worry too much, or not enough?
By the way, and for the record, we do the vast majority of our development in Perl. It's hard to find grad students who know Perl, while on the other hand everybody seems to have at least an academic understanding of Java. Hence this question which I asked a while back.
Why don't you ask the students what they find difficult and make cheat sheets, lectures, etc. for the parts of the job that they have trouble with? Maybe you need to create some introductory Perl lectures or purchase some dead trees. How about a Safari subscription at O'Reilly? I'd ask the students how they prefer to learn, though, before embarking on a training project. Everyone has different learning styles.
I'd also spend some time and capital creating a culture of professional software development at work. It'll be tough since academic programmers are often neophytes and used to kludging up solutions (I'm an academic programmer, btw) but the students will thank you in the long run. Maybe you can all go out to lunch once a week to discuss programming and other topics. You might also want to take some time to do code reviews so people can learn from each other.
With high turnover you definitely need to ensure that knowledge transfer occurs. Make sure you are using source code control and that your students understand proper commenting. I'd also make the students create brief documentation for posterity. If they are getting credit, make them turn in a writeup of their progress once a semester. You can put this in a directory in the project's repository for anyone who inherits it. As mentioned in other posts, a group wiki can really help with knowledge transfer. We use Mediawiki in our group and like it a lot.
One last thing I should add is that I find it helps to keep a list of projects for new developers that relatively easy and can be completed in a month or so. They are a great way for new people to get acclimated to your development environment.
This is a relative question, and should be taken on a case-by-case basis. If the new hire already knows Perl, you don't need to go over this piece of training (yes, you could put Perl as a mandatory prerequisite, but that would significantly limit your applicant pool), and their first bit of training should be something like fixing a bug in an existing application or walking them through an application they will maintain. Though, given that the developers are only there for a year makes me think the development styles are going to vary some (if not a lot).
Getting the new person up to speed with your process is very important, as long as your process works. In this high turnover environment, you should put a strong emphasis on documentation in your process. A Wiki is a great thing to have for this documentation, since it's centralized and any of the developers can access it. Having them try to figure out how a project works by themselves (with little to no documentation) is a waste of both their time and your time.
Perhaps I'm reading too much into the question, but if your university teaches java, why are you using Perl? Wouldn't it make more sense to use the tools that your students already know? This alone would cut the learning curve significantly. [once you eliminate the legacy code of course]
other than that, try:
break the projects up into month-sized bites
overlap the internships by at least 2 months, if not 6, so the new guy can work with and be trained by the old guy(s)
document whatever repeatable processes you have (as was suggested by Mark Nold)
if the grad students are cheaper than full-time pros, quit whinin' ;-) If not, go for the pros.
Have you considered making a "three ring binder" like Macdonalds and many other high turn over industries have? Have one folder which you can print out and hand to the new hire which shows the new hire some basics of getting up and running with Perl in your environment. This should be a "hello world", plus some basic regex and array manipulation. Lastly your manual should go on to show examples of the 5 things you find yourself doing all the time.
The example code may be authenticating users against an external security system, walking through recordsets or using ghostscript to create PDFs. Whatever they are, they should cover the basics of what you meet 80% of the time. More importantly the examples should show users how you expect the code to be written for clarity (eg: naming and approach), and give them some insight into servers and software in use and other practicalities which a generic book won't show them.
You won't get the binder right first time, but since you have a high staff turn over, you'll have plenty of time to test and improve it.
On top of this i would pick a single Perl programming book and give the new user their own copy of your three ring binder, plus "Programming Perl" to keep on their first day. At a cost of $50 per hire i'm sure it's a lot cheaper than the alternatives and you'll have them flipping burgers.... i mean cutting code in no time.
My initial couple of thoughts are that you should:
hire for the position, i.e. it's Perl-centric so make that a big part of the pre-requisites. That way you don't need that piece of training as well.
invest time in the on-boarding process, maybe use a wiki so that you can easily update it to help bringing them on-board.
Edit: Some extra points:
maybe have a chat and see if Perl can be introduced into the curriculum? If not, then make it known six months before the ads go up that applicants need to know Perl. This way you'll get people who have Perl experience and who have actively demonstrated their motivation.
can you open up some small projects so that they could be done by potential candidates during this six months?
approach the design of your large-scale projects so that they can be done in a piece meal manner. This is how The ACE Components have been done iirc.
allow a specific period for documentation and review of the work done by the departing grad student.
allow an overlap period of at least a couple of weeks where the new grad student can work with the departing grad student. They can learn the development environment and they can be guinea pigs for any updates to your wiki.
Still more to come...
HTH
cheers
That is a pickle, but it is not as uncommon in the commercial sector as you would think. I heard a statistic once that the average tenure of a programmer industry-wide is about 18-24 months. Normally I would suggest getting more experienced programmers who would require less ramp-up time and only need to be trained on the problem domain/technology updates and not the basics
I think your best bet is just to ask for about 30-50% more grad students than it will take to actually perform the job to account for the learning and ramp-up time and invest in some additional resources for testing as this environment is a recipe for mistakes since everyone is learning on the job. Also, this is probably difficult given the academic schedule, but try to stagger the start dates as much as possible to maximize the overlap between employees. Pair-programming teams of new-hires/old-hires might also help increase consistency and supplement the training without sacrificing too much productivity.
How much time should I invest in training them, and how much would simply be a waste of time?
Answer: It's not the amount of time or the amount of waste, but perhaps the approach. Would it be possible to video train - video yourself training one person and provide it as training for subsequent students/developers. You can add over time, but it does reduce your time needed to go through the same process.
How much time should they take simply getting acclamated to our process and the project?
Answer: This is all dependent on the person...min. of a day max of 2-3 weeks I would guess on avg.
Are there any specific training practices or techniques that can help with this kind of situation?
Answer: Video training (home made), having the current student/developer create/update a wiki of needed info, points of interest, etc.
Has anyone dealt with a similar situation before?
Answer: Use to be a 12-18 month avg. turnover - I would imagine that it's changed now (longer), but every company has turn-over, but perhaps not forced like yours due to the resource being students.
Do I worry too much, or not enough?
Answer: Knowledge lost through transition is a key risk area...
Is the application something you could consider open-sourcing?
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this question
What are your experiences regarding
project planning and creating hour
estimates for new projects?
What is the approach you are using,
and why has or has it not worked
for you?
Are there any best practices to take
into account?
Estimation Tasks
The principles that I try to use (I don't always get the opportunity) are:
Step-wise refinement
3 point estimates
Risk analysis
Step-wise refinement
When estimating it's important to estimate at the right granularity and to continually break down and add tasks until you're confident in the estimates. Quite often, estimating highlights a lengthy, critical path task that may need more refinement and risk analysis.
Risk analysis
Trying to work out where risks lie in each task (are there lead times for something? is there a lack of knowledge? could a competitor beat you to it? etc. etc.) helps to determine your confidence in the estimates, which allows you to determine how to treat those estimates. Risk analysis also helps to determine if further step-wise refinement is required.
3-point estimates
Specifying the best, probable, and worst case estimates for each task (including design, development, testing, and bug-fixing) helps with risk analysis and planning. The estimates can be used to calculate the most likely duration to hit particular percentage success of that task. Together with information on other related tasks, and risk analysis, a project manager can factor the risk, and other known elements like system testing into the estimates to get a more reliable estimate.
Of course, the granularity of estimates is also important. There's no point in estimating in hours for most tasks. In software, days is usually best, but sometimes it could be weeks or months (such as if you are out-sourcing blocks of work). Choose a time granularity that makes sense for all the tasks in a project (I usually use days for the requirements capture and functional specification phases, and half-days thereafter as I learn more about the tasks and their sub-tasks).
Conclusion
All three of these items feed into each other, so quite often you have to refine each step a number of times. For example, you might have a stab at the requirments stage, then again during functional specification, and again during design specification.
Estimation is a learned skill; the more you do, the better you get. Risk analysis improves as you learn more about what you don't know, 3-point estimates improve as you learn more about what you do know, and stepwise refinement improves as you go through each step of a design process.
If you have the time, revisit your original estimates after you've completed a task and see how the actual time stacks up against your 3-point estimates and your project plan. If it differs, see where the time was lost or gained and try to learn what you can take from that for future projects.
Estimation should not be a daunting task - I always feel like I know more about my work after estimation than before.
I highly recommend the book "Software Estimation: Demystifying the Black Art" by Steve McConnell. It really covers this question well.
There is some excellent information about this in The Pragmatic Programmer. They advise that you use appropriate units of time rather than estimating 130 days estimate 6months. They also advise to concentrate tasks that are most crucial. And avoid making estimates based on sub estimates.
Personally I find it is useful to break the task down to understandable chunks to properly estimate them. If the task is large there are too many nooks & crannies that can hide unthought-of problems. By concentrating on the details of smaller chunks, you can evaluate the potential problems more successfully.
Your question is an NP-Complete problem:) There are many algorithms used to come up with an estimate but they are always just guesses, are never accurate, and many take a long time to execute. Forget hour estimates, use scrum or some other agile framework. Making estimates for a project in hours at its start is simply lying to people.
Don't make hour-based estimates until right before you build the feature and update those estimates continually as you progress on the feature.
Don't forget to include time for testing in your estimates.
Practice, practice, practice. To be safe, overestimate as you refine your estimating abilities. Of course if you're a consultant, this can cost you business. If you're afraid of losing business, under estimate, but be aware you'll be making up the extra hours out of your free time/bottom line.
RE:
If you're afraid of losing business, under estimate, but be aware you'll be making up the extra hours out of your free time/bottom line.
you are better off reducing your hourly rate rather then messing with the hours you present to the client. at least this way, you present the appearance of added value to your client.
LM
Log the time spent in your actual projects and that will help you plan to for the next one, PSP/TSP offer a way to do it
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
Some questions about Function Points:
1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)
2) And is the effort required worth the benefit you get out of it?
3) Which type of Function Points do you use?
4) Do you use any tools for doing this?
Edit: I am interested in hearing from people who use them or have used them. I've read up on estimation practices, including pros/cons of various techniques, but I'm interested in the value in practice.
I was an IFPUG Certified Function Point Specialist from 2002-2005, and I still use them to estimate business applications (web-based and thick-client). My experience is mostly with smaller projects (1000 FP or less).
I settled on Function Points after using Use Case Points and Lines of Code. (I've been actively working with estimation techniques for 10+ years now).
Some questions about Function Points:
1) Is it a reasonably precise way to
do estimates? (I'm not unreasonable
here, but just want to know compared
to other estimation methods)
Hard to answer quickly, as it depends on where you are in the lifecycle (from gleam-in-the-eye to done). You also have to realize that there's more to estimation than precision.
Their greatest strength is that, when coupled with historical data, they hold up well under pressure from decision-makers. By separating the scope of the project from productivity (h/FP), they result in far more constructive conversations. (I first got involved in metrics-based estimation when I, a web programmer, had to convince a personal friend of my company's founder and CEO to go back to his investors and tell them that the date he had been promising was unattainable. We all knew it was, but it was the project history and functional sizing (home-grown use case points at the time) that actually convinced him.
Their advantage is greatest early in the lifecycle, when you have to assess the feasibility of a project before a team has even been assembled.
Contrary to common belief, it doesn't take that long to come up with a useful count, if you know what you're doing. Just off of the basic information types (logical files) inferred in an initial client meeting, and average productivity of our team, I could come up with a rough count (but no rougher than all the other unknowns at that stage) and a useful estimate in an afternoon.
Combine Function Point Analysis with a Facilitated Requirements Workshop and you have a great project set-up approach.
Once things were getting serious and we had nominated a team, we would then use Planning Poker and some other estimation techniques to come up with an independent number, and compare the two.
2) And is the effort required worth
the benefit you get out of it?
Absolutely. I've found preparing a count to be an excellent way to review user-goal-level requirements for consistency and completeness, in addition to all the other benefits. This was even in setting up Agile projects. I often found implied stories the customer had missed.
3) Which type of Function Points do
you use?
IFPUG CPM (Counting Practices Manual) 4.2
4) Do you use any tools for doing
this?
An Excel spreadsheet template I was given by the person who trained me. You put in the file or transaction attributes, and it does all of the table lookups for you.
As a concluding note, NO estimate is as precise (or more precisely, accurate) as the bean-counters would like, for reasons that have been well documented in many other places. So you have to run your projects in ways that can accommodate that (three cheers for Agile).
But estimates are still a vital part of decision support in a business environment, and I would never want to be without my function points. I suspect the people who characterize them as "fantasy" have never seen them properly used (and I have seen them overhyped and misused grotesquely, believe me).
Don't get me wrong, FP have an arbitrary feel to them at times. But, to paraphrase Churchill, Function Points are the worst possible early-lifecycle estimation technique known, except for all the others.
Mike Cohn in his Agile Estimating and Planning consider FPs to be great but difficult to get right. He (obviously) recommends to use story points-based estimation instead. I tend to agree with this as with each new project I see the benefits of Agile approach more and more.
1) Is it a reasonably precise way to do estimates? (I'm not unreasonable here, but just want to know compared to other estimation methods)
As far as estimation precision goes the functional points are very good. In my experience they are great but expensive in terms of effort involved if you want do it properly. Not that many projects could afford an elaboration phase to get the FP-based estimates right.
2) And is the effort required worth the benefit you get out of it?
FPs are great because they are officially recognised by ISO which gives your estimations a great deal of credibility. If you work on a big project for a big client it might be useful to invest in official-looking detailed estimations. But if the level of uncertainty is big to start with (like other vendors integration, legacy system, loose requirements etc.) you will not get anywhere near precision anyway so usually you have to just accept this and re-iterate the estimations later. If it is the case a cheaper way of doing the estimates (user stories and story points) are better.
3) Which type of Function Points do you use?
If I understand this part of your question correctly we used to do estimations based on the Feature Points but gradually moved away from these an almost all projects expect for the ones with heavy emphasis on the internal functionality.
4) Do you use any tools for doing this?
Excel is great with all the formulas you could use. Using Google Spreadsheets instead of Excel helps if you want to do that collaboratively.
There is also a great tool built-in to the Sparx Enterprise Architect which allows you to do the estimates based on the Use Cases which could be used for FP estimations as well.
The great hacknot is offline now, but it is in book form. He has an essay on function points: http://www.scribd.com/doc/459372/hacknot-book-a4, concluding they are a fantasy (which I agree with).
Joel on Software has a reasonable sound alternative called Evidence based scheduling that at least sounds like it might work....
From what I have study about Function Point (one of my teacher was highly involved in the process of the theory of function point) and he wasn't able to answer all our answers.Function point fail in many way because it's not because you have something read or write that you can evaluate correctly. You might have a result of 450 functions points and some of these function point will take 1 hour ans some will take 1 weeks. It's a metric that I will never use again.
No because any particular requirement can have an arbitrary amount of effort based on how precise (or imprecise) the author of the requirement is, and the level of experience of the function point assessor.
No because administration of imprecise derivations of abstract functionality yield no reliable estimate.
None if I can help it.
Tools? For function points? How about Excel? Or Word? Or Notepad? Or Edlin?
To answer your questions:
Yes they are more precise than anything else I have encountered (in 20+ years).
Yes they are well worth the effort. You can estimate size, resources, quality and schedule from just the FP count - extremely useful. It takes an average of 1 minute to count an FP manually and an average of 8 hours to fully code an FP (approximately $800 worth). Consider the carpenter's saying of "measure twice cut once". And now a shameless plug: with https://www.ScopeMaster.com you can measure 1 FP per second, and you don't need to learn how!
I like Cosmic Function Points (because they are versatile) and IFPUG because there is a lot of published data (mostly from Capers Jones).
Having invested considerable time, effort and money in developing a tool that counts FPs automatically from requirements, I shall never have to do it manually again!