Yes, Estimate Software Projects

Post by pjc50 » Sun, Oct 20, 2019, 9:31 PM UTC

nilkn wrote: post #54

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…

As an engineering manager and director, I’ve found a lot of the value in planning (including but not limited to estimation) is having the team, stakeholders, and executives all engage in the exercise of thinking deeply about various ways the next 6-12 months might go. Some folks tend to think that if a plan is produced but not followed exactly, then it wasn’t worth producing the plan. But actually having produced the…

Post by k__ » Sun, Oct 20, 2019, 9:45 PM UTC

jcelerier wrote: post #48

k__ wrote: post #46

Earlier quoted context omitted.

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.

Post by anon9001 » Sun, Oct 20, 2019, 9:56 PM UTC

alecbenzer wrote: post #51

I'm intuitively on team #noestimates but trying to have an open mind/not dig in my heels. I feel like no one does a convincing job at communicating why estimates matter (and how much value you get out of how precise of an estimate). Fundamentally, an estimate (or any piece of information) is really only of value if you're going to do different things based on learning it. E.g., given an estimate, you might: * Priorit…

Post by spoondan » Sun, Oct 20, 2019, 10:10 PM UTC

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…

Post by pas » Sun, Oct 20, 2019, 10:18 PM UTC

XorNot wrote: post #68

pas wrote: post #44

Earlier quoted context omitted.

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 th…

Mine have always had no forewarning, no list of items we'll be potentially estimating (so I could, for example, inspect the codebase and see how much work a 1-line description might be hiding) and then immediately afterwards someone more senior usually rides in and throws a bunch more items at the wall.