133

You seem to assume the primary objective of project management is to produce exact estimates. This is not the case. The primary objective of project management is the same as for developers: To deliver value for the product owner. A product using a lot of slow manual processes rather than automation might in theory be easier to estimate (although I doubt ...


128

I think one of the main advantages is that humans and developers specifically are actually pretty bad at estimating time. Think of the nature of development too -- it's not some linear progression from start to finish. It's often "write 90% of the code in 10 minutes and then tear your hair out debugging for 17 hours." That's pretty hard to estimate in the ...


110

Read Bob Martin's "Clean Coder" (and "Clean Code" while you're at it). The following is from memory but I strongly suggest you buy your own copy. What you need to do is a three point weighted average. You do three estimates for each piece of work: a best case scenario - assuming everything goes right (a) a worst case scenario - assuming everything goes ...


70

So my code is late too. No, it is not your code, it is the code of you and the senior. You are working as a team, you have a shared responsibility, and when you two miss a deadline, it is the fault of both of you. So make sure the one who makes the deadlines notices that. If that person sees that as a problem, too, he will surely talk to both of you ...


67

If the salesmen are also the ones who are in charge, you can say, "Ok, I can go with your schedule. Which features or responsibilities would you like me to sacrifice in order to make your deadline?" That way you're not saying "no" to the people in charge but you're not committing to impossible things. The decision is in their hands how to run the business. ...


60

If you're using Fibonacci numbers (or something similar), it limits the number of options when estimating a story. I worked with a group that used low numbers only: 1, 2, 3, 5, 8, and 13. We had a reference story that was a 5. This enabled us to easily make snap decisions on a story's complexity while doing Planning Poker. The other side effect was that ...


47

In my experience Sales people think that everything is a negotiation where you meet eachother somewhere in the middle. That's basically how they work. They try to sell a product to a client and ask high, the client offers low and in the end a price both parties agree on becomes the agreement. They also take this mentality to the workfloor. They assume you'...


39

You are right - copy-paste works great, and DRY has no point when your task is to produce a program for which either the copied template or the copy will not have to be maintained or evolved in the future. When those two software components have a completely different life cycle, then coupling them together by refactoring common code into a common lib which ...


34

My recommendation: You either include testing time in the ticket, or add a ticket to represent the testing task itself. Any other approach causes you to underestimate the real work needed. While developer time is often a bottleneck, in my experience, there are many teams constrained on test. Assuming the limiting resource is one or the other without ...


32

Two choices really: Quit, or grow a backbone. I think I don't have to explain much about quitting.. that one is obvious. If you can neither take it nor dare to change it, it's the only way to go forward. If you do want to change this, then it is your responsibility to stand up against this. This does need "a backbone", because you will be going against ...


30

This might be a good moment to introduce a quasi-agile approach. If instead of estimating in terms of hours/days you allocated a fibonacci type scale & gave each task a value based on how big it is: 0 - instant 0.5 - quick win 1 - simple change 2 - a couple of simple changes 3 - more challenging 5 - will require some thinking about 8 - a significant ...


27

In a good team, you should have a queue of development tasks assigned to you in an issue tracker. That way, while you are waiting for a reviewer, you could (should) work on next task waiting in that queue. Once you get used to work in that fashion, this will open an opportunity to have your changes reviewed in "batches", thus decreasing delays. If you don'...


26

Do not show them their fault! Try to argue better what changes you make, give them more detailed estimates. Make a suggestion like "We can do this in your X hours instead of mine Y hours, if we will give software testing to outsource". Or "We can do this faster, if we exclude this part of requested functionality".


26

The trick is not to avoid there being blanks. The trick is to fill in those blanks as early as possible in the process of development. You are correct that, if developers make assumptions, they will invariably be wrong and that will cost time redeveloping the software later. But, equally, if business people are expected to do a full up-front design when ...


25

Unless you are estimating something very similar to that which you and your co-workers have done before, +/-10% is ridiculously optimistic. Your management either doesn't have a lot of experience with software, or they're not aware of Large Limits to Software Estimation. That paper has some accompanying supporting material, and a lot of punditry can be ...


25

It's to enable estimation to get better over time, without the estimators all having to adjust their estimation. Rather than everyone involved in the estimate having to think like "OK.. looks like 2 man days.. but last sprint we underestimated everything, so maybe it's really 2.5 man days. Or 3?", they carry on the same as always. "5 story points!" Then, ...


24

You answer the question honestly. You tell them it's a difficult problem, the solution is not obvious, and you are not sure how long it will take to resolve. Promise to update them on your progress every [time frame], so they know you're working on it, and of course, actually send them the updates.


24

Best thing to do is not to throw the new developer into the fire, but instead carve out some functionality and/or bug fixes that the developer should have no trouble jumping in to. Find an area that needs work that doesn't require a person to know the entire architecture, requirements and code-base all at once. Maybe have him or her work on documentation ...


24

It would be better to say "I think that can be done". or "I'll check and get back to you". I've had times where I've said no or counter proposed something. If the customer wants "a browser based application that works without ever being connected to the internet and uses tactile feedback", it probably is possible. But it is expensive and it would be more ...


24

First, congratulations on your contract! Ok, enough celebrating, let's get down to business. ;) I've been a consultant for over 15 years -- here's my advice. In project management, what you are talking about it "contingency" planning -- and you absolutely should do it, else you are likely to disappoint your client (and make yourself unhappy throughout the ...


21

"After giving them the schedule, they start by saying OK you can do it in XX time which differs a lot from my plan." First of all ask them how they calculated their XX time. Suggest to them that a record is made of your estimate and their estimate. Then you can compare the actual against the predictions and see who is more accurate.


21

There are a lot of reasons why deadlines will always be tight. One of the main theories here is Parkinson's law. Parkinson states: "Work expands so as to fill the time available for its completion". So, if you have a project that would take 3 months and you get a 6 month deadline? How long would it take? 6 Months of course, because there's always ...


20

Say "I stand by my estimate." And then of course hit your estimate. When it happens three times, they'll probably trust you.


20

This is the second question in short succession triggered by that article. Good programmer: I optimize code. Better programmer: I structure data. Best programmer: What's the difference? There's another name for this: premature optimization. Never use early exits. That's the "single point of entry / single point of exit" rule. It's a patch over the real ...


19

So from a project management perspective, it is great to solve a task by copying some existing code 100 times and make some minor adaptations to each copy, as required. At all times, you know exactly how much work you have done and how much is left. All managers will love you. Your base assertion is incorrect. The thing that makes software different from ...


19

Emphatically, Yes Testing is part of the development process. If your team actually spends time testing the software, the time spent testing needs to be part of the estimate.


18

Rather than adding a new developer to the team, consider adding an experienced consultant for the two-to-three months period to handle the temporary increase in your company's workload. The idea is to get someone who can handle near-zero start-up time, but at the same time may not necessarily be the best addition to your team. Even if you think that the ...


18

Man days or man hours are as you say concrete. So when a task is estimated at 5 hours and takes 6 it is now a late task. When you have a story that is a 3 points and it takes 6 hours, it took 6 hours, it's not late, it just took six hours. The velocity measurement than is more a factor of how many of those points you get done in a sprint, and that number ...


Only top voted, non community-wiki answers of a minimum length are eligible