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 3 years ago.
Improve this question
This is a software management questions. If i asked to measure a software project task for my every task assigned to me, means how can i do that? Would it be in percentage (or) out of 10 (or) in man hours?
Any suggestions please?
thanks.
I prefer the done/not-done approach. Either a task that is assigned to me is "done", meaning it's been implemented and tested, or it's "not done". If I'm asked how long I've been working on it, I do track man-hours, but it's not a measure of completeness at all.
Another approach that some people use is "in progress", "implemented", or "complete". "In progress" means that they are currently designing and/or implementing a solution, "implemented" means they are done with code and testing (or waiting on QA to validate the fix) and "complete" means it's all coded and tested.
The problem with percentages is the 80/20 rule. The first 80% of the work will take 20% of the time. The other 20% will take 80% of the time. If you have been working on something for 9 hours and are "90% done" implementing functionality, it doesn't mean you'll be 100% done in 1 hour.
If you are working on something (or have been assigned something), and someone asks how long it will take to finish, give your best estimate in hours, days, weeks...whatever. However, don't estimate too soon - take a look at the problem and requirements and never give an off-the-cuff estimate - it'll (almost) always be wrong. When you estimate, look at similar problems that you have solved in the past and use how long it took you to solve them as a guideline or basis for your estimate.
This idea comes from proxy-based estimating, which is part of the Personal Software Process. It's suitable if you are working on a task on your own. I'm not sure how well it will scale for a team.
What do you mean?
If you mean "My boss wants me to estimate how each task will take me." Then that should probably be done in hours.
If you mean something else, you'll have to clarify.
If you are talking about finished tasks, what you're probably being asked for is for the time (probably in hours) dedicated to each one of the tasks.
How do you know that? You should use some timetracking tool, so at the end of the project (or in any moment) you can know how much time you have dedicated to any of the tasks (and/or breaks, meetings...). If you haven't registered your times, you'll have to make up them, and pray :)
If the project is finished, and he needs to know how many hours were spent on a project to bill it to a customer or something, then you should be keeping very accurate track, maybe using a tool or something.
But he might be referring to how effective the task is. For Example, if he asked you to reduce the load on the foozit, then you should measure the load on the foozit before and after your fixes.
But I think what you're asking is "How do we measure tasks in software development?" And the only sensible way to measure a task is hours. Some people like to measure how many lines of code that have been written, how many bugs were found, or how many tests they've written, but in my opinion, those aren't things that should really be measured for most projects.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I know this question has been asked several times on here/programmers and it is quite a common, classic question:
Just how do you accurately give estimates for how long a task will take?
The problem I have is for point-and-click tasks in Windows, I can give accurate estimates. For coding something new (as in using APIs I am not familiar with) I cannot estimate an accurate time to save my life. It's a case of thinking of and saying the first number (of days/weeks/whatever) that comes into my head. For code that uses APIs I am familiar with and apps I can instantly say I can develop (e.g. a notepad-type app) I could give an estimate that is accurate.
Any help appreciated.
Thanks
Focus on the pieces. When you try and estimate a task at a high level, not only is it daunting, but you will fail to accurately factor everything that will comprise the total time.
Instead, do not even try to guess at the total (not only is it not useful, but it can actually bias your estimates of individual tasks), but rather sit down and just try to think of all the sub tasks that comprise the task. If those feel too big, break them down into even smaller sub tasks.
Once you've done this, give each of the sub tasks an estimate. If any of them are larger then about 4 hours, the sub task probably hasn't been broken down enough. Add all of these sub estimates up. This is your estimate.
Using this approach forces you to reason out what is actually required to complete the task and will let you produce better estimates.
Make sure you think of the non obvious steps required to complete a task as well. If you're writing a piece of code, did you include time estimates for writing the associated unit tests? For testing the code? For documenting it?
When converting hours to days, use realistic expectations about how much time you actually spend heads down working. The general consensus is that a developer can complete 4-6 hours of work in any given 8 hour work day. This roughly matches my personal experience.
If you have other team members, you can try a technique called Planning Poker. At its simplest, the idea is to get each member of the team to go off and estimate each of the tasks individually. Once that is done, the team gets together and compares estimates looking for large deviations. This tends to bring to light if the task wasn't clear enough, if there are members of the team who posses relevant information that the others don't, or if there are different assumptions being made by different team members.
When doing your estimations, be aware of your assumptions and document them as part of the estimates. Assuming x, y, & x, task q should take n hours. These could be things like assuming the availability of a QA engineer to test the feature, assuming the availability of a development environment to deploy the feature to for testing, assuming the compatibility of two third party frameworks that haven't been tested together yet, assuming that feature z that the task is dependent on is ready by a certain date... Etc. We make tons of these assumptions all the time without being aware of them. Documenting them forces you to be aware of them and allows other parties to validate that your assumptions are correct. And if the estimates do turn out to be wrong, you have much more information to analyze why.
Even following all of this advice, you will still frequently make inaccurate estimates, but don't feel too bad because our brains are hardwired to produce terrible estimates for abstract tasks. We have a multitude of cognitive biases that affect our ability to gauge task size and effort.
I recommend reading this article for even more information and advice:
http://blog.muonlab.com/2012/04/12/why-you-suck-at-estimating-a-lesson-in-psychology/
I've mostly worked on projects with "smaller" durations, but something that has worked well for me is to break apart the task into small enough sub-tasks that I think I could implement each one in about a day. For some items, this means just two or three sub-tasks, for others, this might mean dozens or hundreds. Add in some overhead percentage that gets wasted on non-productive activities, some overhead for exploring wrong directions, and hopefully you'll get a number that's within a reasonable range of the end result.
what I usually do is breaking down the tasks to small tasks. the largest task should not exceed 2 days. estimating small tasks is not that difficult. each small task has its test time included in the estimation, so I don't end up with a ton of untested code at the end of project.
Breaking down the task to small pieces only is possible if there is a high level design in place otherwise the estimate is just a rough guess which is usually 2 weeks, which is the famous 2 weeks most developers use;)
adding some time to the end of the project to integrate-stabilize-bug fix makes it a reasonable estimate.
Similar to what sarnold mentions, breaking apart the task is key...but it may be more difficult to get it down to fine grained 1-day increments if you don't understand the domain/technologies involved. In your case, I would suggest the following (especially if this clearly doesn't look to be a task that is going to take less than a few days to complete):
1) Firstly, you need to ask around to your team/colleagues to see if they can shed some light (and/or if they've used the same API/technologies you're using). If nobody knows anything, you're going to have to own up to the fact that you simply don't have enough data to hazard a reasonable guess and will need to spend X days to investigate (the amount of time to investigate needs to be aligned with the complexity of the API/Domain you are working with)
2) At the end of the time you've allocated to investigate the new technology, you should be able to do a very basic hello, world-ish type application that uses the API (compiles, links, and runs fine). By this time, you should be in a good position to determine if your task is going to take days, weeks, or months.
3) The key thing to do next is to, as soon as possible, identify any major roadblocks/hiccups that are going to blow away your predictions...this is key. The absolute worst thing you can do is continually go to your manager/customer on the due date and mention you need a significant amount of additional time to deliver. They need the heads up as soon as possible to help remedy the situation and/or come up with a Plan B.
And that's pretty much it...it's not rocket science but you basically provide an estimate once you're in a position to give one and then make sure that you update that estimate based on new, unanticipated events that have a significant impact on your ability to make anticipated dates.
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
What I mean is if I am breaking a programming project estimate down into tasks as much as possible would there be a good maximum to make the tasks. Meaning if I say the max is 4-6 then if any task is more hours than that it needs to be broken down into more tasks. I feel like there is a point where this becomes not much more useful though and think that a max of 10-12 hours is acceptable, the boss does not agree. The idea here is to be able to know as well as possible how much time is needed to complete the task but at the same time I think there is a point where too much breakdown is meaningless until you actually dive into the code. Any thoughts or common practice?
Make the breakdown structure detailed enough to allow you make a proper estimation, but not too detailed so you'll have trouble maintaining and tracking it later, when things change (not if things change, but when things change).
It doesn't really matter the number of hours a task in WBS is estimated.
When I was writing my own time breakdowns for a task, I found the most useful number to go with as a goal for a single task to be max'd at about 4 hours. Then, if it turned out to be really difficult and take a lot longer than I expected, it wasn't so terrible.
I don't think it is useful to actually hold any of these projects as meaningful unless:
1.) The person performing the task created the projection.
2.) The person creating the projection is familiar enough with the work.
At my last job, I didn't even start projecting tasks until I had been there for three months. After that, it was another month or two before my projections were meaningful.
I think that this is a very individual thing. If you are used to thinking about things at an extremely detailed level, it makes more sense to have lots of small tasks. If you like to think of things in more general terms, it makes sense to have a few big tasks. I believe if you and your boss try and enforce this sort of personal preference into task projection, you will find that your projections are meaningless at best and a creator of hostility at worst.
I hope my experiences and expression of them is useful to you.
-Brian J. Stinar-
What does a task look like?
write a document? Write a chapter of document? Write a sentence in a document?
Write a programme? Write a class? Write a method?
I think the following need to be true:
1). A task is big enough so that you know you've finished it. A single sentence or method doesn't stand alone. You typically can't deliver something that small in isolation, the receiver can't "test" it.
So, for example, you can unit test, document and check some code into an SCM that's a task.
I can't imagine tasks smaller than one hour, and typically for me they are half-days.
2). A task is small enough that you can be confident you can do it in the estimated time. You've analysed the problem well enough to understand the chunks.
People are not machines.
Having that said, the way I see it there are two main development modes:
develop
Maintain/fix
For the second one you can gain experience on how long tasks should take - the developer knows the code and most of the times he can give a good prediction what is wrong and what should be done to make it work (in that case tight monitoring + buffer to keep getting good cooperation is in order, if the developer can't get a good estimation - that is an indication of a very big problem)
For the first one - it's more complicated:
if this is hard labor job - one that requires no brain and just take the program from point a to point b than... you can define tight schedule.
If you need the developer to get creative, to think about good implementation etc... You can not wait forever for a masterpiece, yet you will not get much from a developer that have only survival thoughts :)
Learn about Agile -where the team leaders and the developers sets the goals together- the goals may be very demanding but within the development period the developer which feels as responsible as the manager... can manage his time.
So sometimes, with the correct management system - tasks can and perhaps should be a week long.
There is no magic number. Understand your type of programing and find an appropriate management management system.
Good luck
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
Our project manager usually consult developers how many hours they need to implement some functionality asked by client. Is this consistent with the principles of management? Do you or your project managers do the same?
There's no other way to know how long something will take. You should be thankful, really, that your PM is even consulting you -- too many managers get together with the customer and promise impossible timelines, then expect the devs to live up to their outrageous promises.
Certainly. Without getting estimates for development time no-one has a clue what is going on. You need to be able manage stakeholders expectations, in this case your clients. And better the estimate comes from the horses mouth (in this case the developer) rather than the PM promising impossible time-frames!
Developers sometimes get funny about doing estimates of this nature (I know I do), but it is critical to running a business. The easiest way to approach it is to understand that the PM just wants information. Be open and honest - don't say things will be done when they won't, and explain when and why things might be unknown, or why there might be an element of risk around your estimate.
Yes, you can't get away from PMs wanting an exact figure of how long something will take.
My approach has been to give estimates with +/- values. I'm 60% sure I'll finish this in a week, there's 30% chance it will be longer, and 10% chance it'll be 2 days. Takes a while for a PM to get used to that idea, but it's the reality of the situation. As someone wise once said, only [insert deity here] can change reality, regardless of how much the PM would like it to be different.
We know that Dev is an in-exact science, the tension of traditional project management, meeting creativity and best guess estimation is probably the single biggest headache of professional development. A really good learning from Agile is just how bad we are at estimating, most Dev's will underestimate 80% of time - that's my estimate anyway.
Yes, it's his job, because time = money
If you consider the fact that
you are part of a business
that the purpose of the business is
to make money
Time = money
Then it is makes perfect sense that your manager asks you "How much time will this take" because it translates perfecty into "How much will this cost".
Someone must pay that cost, it will either be a customer, or your company.
The PM will use your estimates to ensure the project comes in on time and with in budget. If you say something will take 10 days, and thats 5 days more than he'd like, then it's up to him to either a) cut some other functionality to get this in or b) extend the deadline.
So thats the PMs job, to get estimates from you, and juggle the balance between deliver times and functionality delivered.
YOUR JOB is to provide the best, most honest estimates you can. Like someone else said, always give a confidence prcentage. "2 days, 30% confident" "Possibly 1 day, could be 3 worst case" etc.
It can be annoying to be constantly asked, but it's his job.
P.S. Sometimes the answer "I don't know" is perfectly acceptable, however you should phrase it as "I don't know, I need to look at it a little more and I'll have a better idea then".
Hope this helps.
You have obviously never worked for a manager that does not ask for an estimate from you. Otherwise you would know better than to question whether they should do it. :-)
Seriously, very few managers can make realistic estimates on the time needed to provide particular feature, mostly because it's not their job to really undersand all the technical intricacies. A good manager will realize this and will always involve the developers to get good estimates of the work that can be fit in when creating the schedule.
I think it's sounds pretty good. It seems better that he asks for an estimate by the people that are going to do it than just promise something to the client that can turn up to be unrealistic.
On the condition that he accepts your answer.
If a PM has a number in mind when he asks you the question he shouldn't be surprised by his results.
A project manager should always ask developers how long something will take. What the project manager does with those estimates will vary considerably depending on their own experience and skill.
If the PM has lots of development experience, they should be able to assist more junior developers in determining whether or not the developers estimate is valid - and hopefully point out why they think there estimate is wrong. Also, a PM should be able to add in other factors that the developers tend to forget - meeting time, sickness, time on SO etc, that all impact on their time.
If the PM has little development experience then the most accurate estimate will come from the developers.
One of the main advantages of this is that it helps you to find out early in the game that you are overwhelmed by a task: If you can't time it, you probably don't know how to tackle it.
Also, if your estimate more than a week, then it is probably off by 100-1'000'000% (a.k.a "pure speculation"). If you come up with "several weeks", I suggest that start breaking up the task and estimate the pieces. This will help you notice danger zones (where you really have no idea how long it is going to take).
This process will allow your manager to get you the help/tools you need to complete your assignments in time (instead of noticing something important missing two days before the deadline).
If you're interested more in these things, I suggest the book "Death March" and the Extreme Programming site (especially this page). Take XP with a grain of salt: Rules are never going to solve your problems; they just tell you what worked for other people. You will always use them judiciously.
Asking is much better than assuming.
We had a business manager recently mention in a all-hands staff meeting that a bunch of new features were on the way and they shouldn't take too much effort to implement. This was news to the development team!!
Yes. It is better the manager consults the team on the time required. And the team has to come up with the actual time line taking into considerations all the factors. The onus is on the team to justify the time required for giving quality output. If the Manager is good enough, he/she would appreciate it and agree with the team.
Its a fair question, just don't ever reply with an off the cuff estimate. Always derive estimates from some sort of specification, that way your both on level ground, thats my advice anyway.
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
Might be subjective and/or discussion.. but here goes.
I've been asked to estimate a feature for the next big thing at work. I break it down.. use story points come up with a estimate. The feature however calls for interfacing with GoDiagrams a third party diagramming component in addition to various other company initiatives.. (a whole set of 2008_Limited_Edition frameworks/services:). I've been tracking myself using a burn-up chart and I find that I'm unable to sustain my pace primarily due to "spikes".. Definition
I estimate for 2 points a week and then I find myself working weekends (well trying to.. end up neither here nor there) because I can't figure out where to hook in so that I can preview user-actions, show a context menu, etc. In the end I spend time making spikes that throw my schedule off-track... and decreases its value.. doesn't give the right picture.
Spikes are needed to drive nails through the planks of ignorance. But how are they factored into the estimation equation? Doing all required spikes before the feature seems wrong.. (might turn out to be YAGNI) Doing it in between disrupts my flow. Right now it's during pre-iteration planning.. but this is pushing the touchline out on a weekly basis.
I guess you are constantly underestimating
what you do already know about the 3rd party component
how long it takes you to create usable/helpful spikes for unknown areas
1. Get better at estimating those two things.
So, it's all about experience. No matter what methodology you use, they will help you to use your experience better, not replace it.
2. Try not to get lose track when working on those spikes.
They should be short, time boxed sessions. They are not about playing around with all the possible features listed on the marketing slides.
Give them focus, two or three options to explore. Expect them to deliver one concrete result.
Update(Gishu): To summarize
Spikes need to be explicit tasks defined in the iteration planning step.
If spikes exceed the timebox period, stop working on it. Shelve the associated task. Complete the other tasks in the current iteration bucket. Return to the shelved task or add a more elaborate/broken down spike to the next iteration along with the associated task. Tag a more conservative estimate to the generation 1 spike the next time.
If you run out of time in your timeboxed spike, you should still stop and complete your other committed work. You should then add another spike to your next iteration to complete the necessary work you need to complete in order to accurately estimate the task resulting from the spike.
If there is a concern over spiking things for too long and this becoming a problem - this is one reason I like 1 week iterations. :-)
#pointernil..
It's more of no estimation coupled with a Indy-Jones Head-First approach to tackling a story. I estimate stories by their content.. currently I don't take into account the time required to find the right incantation for the control library to play nice. That sometimes takes more time than my application logic.. So to rephrase the Original question, should spikes be separate tasks in the iteration plan, added on a JIT basis before you start working on a particular story?
My Spikes are extremely focussed.. I just can't wait to get back to the "real" problems. e.g. 'How do I show a context menu from this control?' I may be guilty of not reading the entire 150+ page manual or code samples.. but then time is scarce. The first solution that solves the problem gets the nod and I move on. But when you're unable to find that elusive event or NIH pattern of notification used by the component, spikes can be time-consuming. How do I timebox something that is unknown? e.g. My timebox has elapsed and I still have no clue for plugging-in my custom context menu. How do I proceed? Keep hacking away?
Maybe this comes in the "Buffering Uncertainity" scheme of things.. I'll look if I find something useful in Mike Cohn's book.
I agree with pointernil. The only issue is that your estimates are incorrect. Which is no big drama, unless you've just blown out a 3 million dollar project of course :-)
If it happens once, its a learning experience. If it happens again and the result is better, then you've got another learning experience under your belt. If you are constantly underestimating and your percentages are getting worse, you need to wisen up a bit. No methodology will get you out of this.
Spikes just need to be given the time that they need. The one thing I've seen happen repeatedly in my experience is that people expect to be able to nail a technology within a couple of hours, or a day. That just doesn't happen in real life. The simplest issue, even a bug caused by a typo, can have a developer pulling their hair our for huge chunks of time. Be honest about how competent yourself or your staff really are, and put it in the budget.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I mean name off a programming project you did and how long it took, please. The boss has never complained but I sometimes feel like things take too long. But this could be because I am impatient as well. Let me know your experiences for comparison.
I've also noticed that things always seem to take longer, sometimes much longer, than originally planned. I don't know why we don't start planning for it but then I think that maybe it's for motivational purposes.
Ryan
It is best to simply time yourself, record your estimates and determine the average percent you're off. Given that, as long as you are consistent, you can appropriately estimate actual times based on when you believed you'd get it done. It's not simply to determine how bad you are at estimating, but rather to take into account the regularity of inevitable distractions (both personal and boss/client-based).
This is based on Joel Spolsky's Evidence Based Scheduling, essential reading, as he explains that the primary other important aspect is breaking your tasks down into bite-sized (16-hour max) tasks, estimating and adding those together to arrive at your final project total.
Gut-based estimates come with experience but you really need to detail out the tasks involved to get something reasonable.
If you have a spec or at least some constraints, you can start creating tasks (design users page, design tags page, implement users page, implement tags page, write tags query, ...).
Once you do this, add it up and double it. If you are going to have to coordinate with others, triple it.
Record your actual time in detail as you go so you can evaluate how accurate you were when the project is complete and hone your estimating skills.
I completely agree with the previous posters... don't forget your team's workload also. Just because you estimated a project would take 3 months, it doesn't mean it'll be done anywhere near that.
I work on a smaller team (5 devs, 1 lead), many of us work on several projects at a time - some big, some small. Depending on the priority of the project, the whims of management and the availability of other teams (if needed), work on a project gets interspersed amongst the others.
So, yes, 3 months worth of work may be dead on, but it might be 3 months worth of work over a 6 month period.
I've done projects between 1 - 6 months on my own, and I always tend to double or quadrouple my original estimates.
It's effectively impossible to compare two programming projects, as there are too many factors that mean that the metrics from only aren't applicable to another (e.g., specific technologies used, prior experience of the developers, shifting requirements). Unless you are stamping out another system that is almost identical to one you've built previously, your estimates are going to have a low probability of being accurate.
A caveat is when you're building the next revision of an existing system with the same team; the specific experience gained does improve the ability to estimate the next batch of work.
I've seen too many attempts at estimation methodology, and none have worked. They may have a pseudo-scientific allure, but they just don't work in practice.
The only meaningful answer is the relatively short iteration, as advocated by agile advocates: choose a scope of work that can be executed within a short timeframe, deliver it, and then go for the next round. Budgets are then allocated on a short-term basis, with the stakeholders able to evaluate whether their money is being effectively spent. If it's taking too long to get anywhere, they can ditch the project.
Hofstadter's Law:
'It always takes longer than you expect, even when you take Hofstadter's Law into account.'
I believe this is because:
Work expands to fill the time available to do it. No matter how ruthless you are cutting unnecessary features, you would have been more brutal if the deadlines were even tighter.
Unexpected problems occur during the project.
In any case, it's really misleading to compare anecdotes, partly because people have selective memories. If I tell you it once took me two hours to write a fully-optimised quicksort, then maybe I'm forgetting the fact that I knew I'd have that task a week in advance, and had been thinking over ideas. Maybe I'm forgetting that there was a bug in it that I spent another two hours fixing a week later.
I'm almost certainly leaving out all the non-programming work that goes on: meetings, architecture design, consulting others who are stuck on something I happen to know about, admin. So it's unfair on yourself to think of a rate of work that seems plausible in terms of "sitting there coding", and expect that to be sustained all the time. This is the source of a lot of feelings after the fact that you "should have been quicker".
I do projects from 2 weeks to 1 year. Generally my estimates are quite good, a posteriori. At the beginning of the project, though, I generally get bashed because my estimates are considered too large.
This is because I consider a lot of things that people forget:
Time for bug fixing
Time for deployments
Time for management/meetings/interaction
Time to allow requirement owners to change their mind
etc
The trick is to use evidence based scheduling (see Joel on Software).
Thing is, if you plan for a little extra time, you will use it to improve the code base if no problems arise. If problems arise, you are still within the estimates.
I believe Joel has wrote an article on this: What you can do, is ask each developer on team to lay out his task in detail (what are all the steps that need to be done) and ask them to estimate time needed for each step. Later, when project is done, compare the real time to estimated time, and you'll get the bias for each developer. When a new project is started, ask them to evaluate the time again, and multiply that with bias of each developer to get the values close to what's really expects.
After a few projects, you should have very good estimates.