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


131

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


111

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


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


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


31

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

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

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

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

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

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

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


17

Short answer--you can't. As soon as you expose an application over a network, you've introduced an infinite number of possible variations and conditions that you cannot possibly predict to 100% certainty. What happens when a user does something incredibly stupid or unpredictable? What happens when a malicious user works out your processes and comes up ...


17

The way I understand it, a story-point is an estimate of relative effort, not man-hours. The effort required of a story isn't going to change just because a pair is working on it, so it doesn't make sense for the story points to change... Also, velocity is derived from the history of what got done in the previous sprint(s). If you pair on some stories and ...


16

Estimation in agile can be performed using various tools, as long as it is based on relative sizing of stories (effort required to complete one story as compared to the other). Fibonacci series is just one of those tools. Some teams use the 't-shirt sizes' to estimate, Small, Medium, Large, XLarge. In short, planning poker (agile estimation) does not require ...


16

Boss: AJ, We have 3 dogs, 2 rabbits, a catapult, and a nun. We need to find a way to get all 7 (yes, the catapult too) over a 20-foot wall and into the lake on the other side without the dogs eating any rabbits, and without drowning the nun. How long will it take you to come up with the solution? See, the problem estimating how long it will take to solve a ...


16

You are correct, there is not a formula to convert story points to hours. You can get a pretty lossless conversion of meters to feet, and vice versa, but you can't say a 3 point story will take X hours, so a 5 point story will take Y hours (solve for Y). HorusKol touched on this next part. Your sprint velocity as a team can help out with the longer term ...


15

if you can't estimate - and in this scenario it sounds like there really is no way to know in advance how long any particular part of the process will take - then the next-best option is to time-box the effort: how much time you're willing to spend on it, whether you get anywhere or not once you get into it, you may have a better idea of how to estimate the ...


15

Your back-end table stories no longer require eight points of effort. “A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“ scrum.org If you continue to estimate back-end table stories at eight points then you will skew your velocity as a ...


14

The abstraction is sort of the point. Using the 'man day' as a measurement has a number of pitfalls, including: If the team isn't familiar with the tech they are going to be using, then it can be really hard to give real-time estimates of how long a task might take. They are much more likely to be able to give good relative estimates - e.g. "task A will ...


14

"As long as they need to be, and no longer." The thing to realize here is that meeting time to saved development time is in no way linear. For your team, for your company, for this topic, then 1 hour of meetings might save 2 hours of dev work. If you have 10 hours of meetings, another hour of meetings might save 0 dev work. Hell, it may save you -2 hours of ...


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