Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Yes, Estimate Software Projects

blog.pragmaticengineer.com

Post reply on HN
Print view View original

41–50 of 96 posts

Re: Yes, Estimate Software Projects

#41

Post by davidjnelson »

Osiris wrote: post #11

My current employer switched from SCRUM to KANBAN. We're broken up into person squads. Epics are created by product by engineers are involved in kickoff and story breakdown. We use KANBAN cycle times to estimate delivery dates. For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date. It…

Interesting. Who made the decision to switch and who pitched it to execs? In my experience an executive is the only one who can make this decision. Extremely curious how this worked out.

Re: Yes, Estimate Software Projects

#42

Post by cpeterso »

joe_blank wrote: post #7

Being pretty young and just getting used to making estimates, this was a wonderful read! Having to guess how long a project will take is still very scary for me. Is there any way to get over the fear of others disagreing? I always feel like I'm about to embarrass myself by either estimating to high or to low...

For more practical information on software estimation, I recommend apenwarr's "An epic treatise on scheduling, bug tracking, and triage" (2017):

https://apenwarr.ca/log/20171213

Re: Yes, Estimate Software Projects

#43

Post by mobjack »

jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

When you keep stakeholders updated early, you force them to make hard decisions about their product so you know what to prioritize.

It makes everyone focus on what is most important.

Are those features really necessary for the release? Can we change the requirements to accomplish the goal easier? Is it important enough that we should delay it?

Without a deadline, engineers waste time working on stuff that is fun and interesting to them and not the hard stuff that is needed to ship a product across the finish line.

I do that along with every other engineer I know. It is human nature.

Re: Yes, Estimate Software Projects

#44

Post by pas »

shaggyfrog wrote: post #31
UK-Al05 wrote: post #23

Earlier quoted context omitted.

In many ways the story points are outside view. You estimate complexity, then you look at how long it took to do stories of simular complexity before.

In theory. In practice, - stories are not always the same "size", - someone correlates story points to a time unit, - everyone estimates stories differently, - not everyone understands how to do the thing because they've never done the thing, - everyone understands complexity differently, - people makes estimates to what they think everyone else will say, - no one ever goes back and updates an estimate, - the estimat…

It's not a problem if sizes are different. That's why they are scored.

Points are only mean something with a constant team anyway. No point in comparing between different companies, teams, projects.

Also, you can estimate time based on points. After you have some baseline velocity for the given team-project setup.

...

I don't know what kind of estimation meetings you had to suffer through, but the ones we did were the usual SCRUM poker, and then the PM tool just gives you the estimate based on the team's past velocity. No hand-waving. It's data driven. And anyone has any problem with the date can talk to the PM and decide which features to cut/change.

Re: Yes, Estimate Software Projects

#45

Post by pas »

awinter-py wrote: post #34
shmundada wrote: post #26

Earlier quoted context omitted.

> make time to identify & resolve unknowns before committing to features / timelines. I find it difficult to identify unknowns before I actually start working on it. Personally it makes sense to just give it a go as estimating it correctly may be as time consuming as completing it. Especially true for one off feature or bugs in large codebase.

That's fine for smaller chunks of work, and you're right that resolving uncertainty is not cheap. But if you're doing resource planning for a large organization and you need to decide between high-value, long-timeline projects, that decision is irresponsible without some homework up front to validate the timelines. Large projects involve high- and low-uncertainty work and it's useful to do some of the former before s…

Agreed. Usually the problem is that technical folks are involved too late. (They are the ones that actually think through the requirements after all.)

Re: Yes, Estimate Software Projects

#46

Post by k__ »

jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

I really hate this estimation crap.

We do it at the start, people change their mind 10 times and then we deliver something different and it's considered business as usual.

But if I suggest just once that we cut the estimates out, people get angry and afraid.

As if they all WANT to be lied at...

Re: Yes, Estimate Software Projects

#47

Post by pas »

dstroot wrote: post #20

Cost, quality, and speed. Pick any two. You can’t have all three. There are several modes of delivery. Some projects have fixed delivery dates because it’s externally imposed. For example a regulatory requirement. Some are internally imposed - an executive imperative. Projects with fixed dates need dedicated resources and a highly functional scope management process. Others are “innovation/exploratory”. For example “…

Sure, estimation is needed. But the more important thing is that project _management_ must involve the constant updating of those estimates.

After all estimates should be data based. As more data comes in they should get more accurate not less.

If they don't that's a sign of basing them on hope or whatever ideology someone found instead of hard truths.

Re: Yes, Estimate Software Projects

#48

Post by jcelerier »

k__ wrote: post #46
jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

I really hate this estimation crap. We do it at the start, people change their mind 10 times and then we deliver something different and it's considered business as usual. But if I suggest just once that we cut the estimates out, people get angry and afraid. As if they all WANT to be lied at...

> As if they all WANT to be lied at...

well... I mean, that's the whole point - end game is to have engineer-sourced figures that you can show to your banker so that they put cash in your account and become subject to the opportunity cost paradox when it's too late and you have to move your deadlines.

Re: Yes, Estimate Software Projects

#49

Post by bastijn »

davidjnelson wrote: post #40
klenwell wrote: post #5

I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt. In Thinking Fast and Slow, Daniel Kahneman offe…

> If your deadline is fixed, be ready to scale back. True. Honestly, what else can you do if a deadline is approaching than to cut scope? Even enforced death marches aren’t necessarily going to solve it...

You have the four knobs to turn. Resources ($, FTE), scope, deadline, quality. The dilemma typically is that the one calling the shots wants to fix three of them and does not accept the fourth knob has to be turned. Another is that close to a deadline the resources knob doesn't matter anymore unless the deadline knob is turned. And when the deadline knob is turned it makes the scope knob feeling very attractive suddenly to the same kind of people.

In such situations having people skills helps. You can say no in many ways but you have to try and understand their problems as well. That big conference, competitors having announced something recently, you name it.

Re: Yes, Estimate Software Projects

#50

Post by [deleted] »

mobjack wrote: post #43
jasonpeacock wrote: post #29

This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices. They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines. Then they admit that "delays are normal and expected" - so…

When you keep stakeholders updated early, you force them to make hard decisions about their product so you know what to prioritize. It makes everyone focus on what is most important. Are those features really necessary for the release? Can we change the requirements to accomplish the goal easier? Is it important enough that we should delay it? Without a deadline, engineers waste time working on stuff that is fun and…

[deleted]
Post reply on HN