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

11–20 of 96 posts

Re: Yes, Estimate Software Projects

#11

Post by Osiris »

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's important to note that we've convinced management that these are approximate completion dates, not deadlines. The dates are used for planning upcoming features and which squad will be free first to take it on. However, there's still plenty of adaptability.

Of all the places I've worked, this model is one that I've found to be the most productive.

Re: Yes, Estimate Software Projects

#12

Post by abhorrence »

journalctl wrote: post #3

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…

> Is this why so many Apple products have been increasingly low-quality?

Potentially, however the author makes another mistake: assuming that Apple, Google or Facebook actually know what they're launching at the time they set the date. I've heard many stories of "big bang projects" being pulled at the last minute.

Re: Yes, Estimate Software Projects

#13

Post by george_ciobanu »

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

No better way to learn than by trial and error. If your team is reasonable they will point out why something is easier or harder than you thought. And that's part of learning so you shouldn't feel bad about it. Would you be upset at a child learning a second language or an instrument? No, that's why they are learning because they don't know. The worst thing you can do is not try to estimate. Just make sure to do your homework, whatever that means for your projects: look at existing code, try to do a detailed breakdown that shows why you think it takes this long, read API docs etc.

Re: Yes, Estimate Software Projects

#14

Post by mikewhy »

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…

I really, really like Kanban as well. Seems the hardest part is selling it to upper management.

Re: Yes, Estimate Software Projects

#15

Post by pinkfoot »

> 100 plus people to port Skype in 16 months.

To all employers out there: if you put me on a project with a hundred others to port a wee VOIP front-end to another platform, I too can get it done in a year and a half.

Re: Yes, Estimate Software Projects

#16

Post by generatorguy »

I have to have all of the control system software ready for a power plant the second construction is finished enough to begin turning things on and commissioning them. This frequently overlaps with electrical, mechanical, and civil works still in progress. Not starting as early as possible means not finishing as early as possible which means holding up the transition from a construction project with construction loans to an operating asset earning revenue with much more favorable financing, which is significant in hundreds of millions of dollars projects.

All of the software needs to be ready to start commissioning on an unknown date. A lot of the programming can’t start until equipment details are received, which makes the whole thing a game of identifying what information you need and pointing out that if you don’t have it by x date your deliverables will be late, or you’ll have to work overtime or bring more people on it which will cost extra.

Having a good estimate for how long each piece of the programming will take and what inputs are required to finish it is crucial to having everything ready to go on D day or a bulletproof paper trail of how you’ve been fucked over by other people who couldn’t deliver, because those liquidated damages are no joke.

To me time estimates are a major component of engineering.

Edit: remove snark

Re: Yes, Estimate Software Projects

#18

Post by romanows »

The article seems contradictory. Is it really estimating if you drop features you can't finish to ship by a deadline? Is a 16 month estimate worthwhile when you screw around for 12 months before getting serious and then getting it done? If the upshot is just to keep a conversation going with stakeholders and always be working on the most important functionality, isn't this mostly accomplished by 2 week sprints with a touch of externally set deadline pressure (e.g., WWDC)?

Re: Yes, Estimate Software Projects

#19

Post by delusional »

journalctl wrote: post #3

> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…

> there aren’t any explicit requirements but there are requirements, we just don’t know what they are and also they change every sprint so good luck

What a sad way to view your profession. The requirements aren't hidden from you, and they don't just randomly change. You can't get them up front because no one has any idea what we are looking for. Solving a small problem usually reveals more of the problem.

I don't think you believe in long requirement documents either, but I sometimes hear arguments very similar to yours.

Re: Yes, Estimate Software Projects

#20

Post by dstroot »

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 “let’s build a bitchen website”. What does that mean? What is the definition of done? This requires an agile, “integrate until we are satisfied or run out of funding” project that may or may not have dedicated resources.

No matter what, in a corporate environment you will need to be accountable to cost, which is simply humans * time. So some type of estimate will be needed.

Post reply on HN