2024-05-01 18:32 UTC
Replies (17)
-
@polotek@social.polotek.net 2024-05-01 20:37
I'm glad I asked this question explicitly in this way. Lots of great info in the replies. Thank you all for being thoughtful and candid. I have some thoughts, but they'll have to wait until later. I will share some of my own experience though. I forget to do that sometimes.
-
@depereo@mastodon.social 2024-05-01 18:53
@polotek@social.polotek.net > If you feel that you were never taught the skill in any real sense, what do you feel you're doing at work when you're asked for estimates? Are you making it up? Have you developed your own personal guidelines? 100% made up. Finger in the wind, double it, double it again. 0% confidence in timeframes.
-
@janl@narrativ.es 2024-05-01 18:54
@polotek@social.polotek.net I was once consulting for a project that did estimation on a two year scale and I just couldn’t believe what I was seeing. I later asked the PM how they did this and he referred me to (no surprise here) Steve McConnell’s Software Estimation book. While a bit heavy on precision and process, the first few chapters teach the most important bits: 1/N
-
@jimw@mefi.social 2024-05-01 18:54
@polotek@social.polotek.net I think I learned the theory of different models of software development in college (early 90s, so pre-agile) and estimation was probably part of those. My first job out of college was for an educational/games company (CD-ROM releases!) and they definitely put a lot of effort into generating estimates and deriving deadlines from those. I can’t put a finger on how I learned to do it or how well I did it, but as I got promoted to team lead on a project it was certainly part of what I did. There was an expectation that we would get better at it individually and organizationally, but also an understanding that it was hard.
-
@janl@narrativ.es 2024-05-01 18:56
@polotek@social.polotek.net 1. You can only estimate with confidence in a team that has estimated before and learned from the actual-estimate difference. Usually you need to do this a couple of times before your estimates hit. 2. Estimation confidence is a funnel, wide at the beginning of the project, highest confidence is just before the end of the project.the funnel starts with a 100% confidence interval at *least*.
-
@janl@narrativ.es 2024-05-01 18:56
@polotek@social.polotek.net 3. R&D cannot be estimated, but having experts do a timeboxed exploration usually gives enough of a clue to get started. 4. Large tasks can’t be estimated. Make them smaller. Then even smaller.
-
@ak@mastodon.social 2024-05-01 19:10
@polotek@social.polotek.net 1. Some teams I have been on had guidelines for “point sizes” or a rule like “all sprint tasks must be broken down to this size +/- 50%”. 2. At the project level, I learned by asking a TPM to teach me their ways, and read a lot of blogs plus a book about it (Software Estimation by McConnell). Back in MechE school we did a bit of Gannt Chart / dependency analysis etc. TPM tips: weighted averages for tasks, mapping out dependencies so the schedule isn’t just # of days / # of people.
-
@notNapoleon@tech.lgbt 2024-05-01 19:22
@polotek@social.polotek.net Hey! 18 years industry experience here. I have never been taught how to estimate projects, formally or otherwise. What little I know about it is from trial and error. When asked for an estimate, I compare it to something similar I've already done, and just kind of guess. System knowledge plays a part too. Like, if I know I have to touch some eldritch horror of a class, I'll add time to the estimate for that. So, I guess you'd say I have personal guidelines, but they're informal/instinct based. I am not at all confidant in my estimates. Also, my team does not do any kind of retrospective on estimates - we never go back and say "why did this take more/less effort than we expected?" Without that kind of reflection, I find it very hard to learn and improve.
-
@spoltier@qoto.org 2024-05-01 19:33
@polotek@social.polotek.net gut feeling from previous tasks, but it's almost always "story points" which aren't supposed to be directly about time, so... In my first jobs that didn't use some kind of agile, I never had to estimate tasks.
-
@eaton@phire.place 2024-05-01 19:50
@polotek@social.polotek.net absolutely had to develop my own guidelines; breaking the “feels like I could write X in a week or so” gut checks and relying on project decomposition and historical project numbers, etc. was tough.
-
@nfagerlund@mastodon.social 2024-05-01 20:05
@polotek@social.polotek.net I wasn’t taught, & have low confidence. What I do instead: - Analyze ordering dependencies. - Analyze obligations to or dependencies on other teams. - Use ^^ to see what can be done in parallel. - ID which tasks are actually “learn/discover something” & flag them for risk. - Separate “nice to have” from “must have”. Then, guess at time for external folk. But the above is what we need while we’re doing the work and adjusting to changes in scope or resources.
-
@JasonPunyon@fosstodon.org 2024-05-01 20:14
@polotek@social.polotek.net The only explicit conversations I've ever had are about story points and t-shirt sizing. They were fairly useless. I am making it up. But it's not unprincipled. 1. Estimates involve negotiation, like a contract. I don't make estimates, we agree to them. 2. They (PMs or whoever) should set the terms of the contract (requirements), and I should set the price (make the estimate). 3. That means they should know the terms, and my job is to learn them. I ask a lot of questions.
-
@aredridel@kolektiva.social 2024-05-01 20:18
@polotek@social.polotek.net - Definitely taught myself the skill, and have it to a sort of rough fidelity. Lots of explicit conversations about how to estimate in different contexts; about 1/3 of them are approaches that would actually work. And fewer than that actually did thanks to organizational dysfunctions around requirements gathering. - I've been explicitly told to wing it and give an off the cuff guess _remarkably_ often. And also held to those estimates as if I'd agreed to be accountable to them. - I've been handed estimates from project managers with no technical input on them in multiple organizations. - Confidence? Middling. I get to exercise the skill in an unpoliticized environment extremely rarely.
-
@cratermoon@zirk.us 2024-05-01 20:19
@polotek@social.polotek.net Yes on having conversations, no on training. The better teams used points or shirt size; those close to the project understood their imprecise nature. I read widely. no. 1: you can only estimate something you've done before, as another comment mentioning Steve McConnell says. Look back is important. Retrospectives and velocity aren't enough. Individual programmers need to be taught how to record their work and compare results with estimates.
-
@mhkohne@mastodon.social 2024-05-01 20:29
@polotek@social.polotek.net 1) I've had some conference talks and I've done CSM training, so I kinda have a clue how to estimate. 2) I'm making stuff up based on a guess as to what is desired. It gets better the better I'm able to break things down, but I'm usually so stressed about today's stuff that I'm unable to really break the new task down well. 3) I have little to no confidence in my own estimates, partly because I CAN'T measure success - too many side tasks to count.
-
@internetross@social.coop 2024-05-01 20:33
@polotek@social.polotek.net I use Jacob Kaplan-Moss' technique as a reference. This was eye opening when I found it because it was the most rigorous framework I found that felt realistic for software dev. Over my career I've developed a rule of thumb to double whatever my initial gut instinct is if I'm providing a ballpark. This has been shockingly accurate for smaller, less complicated work. https://jacobian.org/2021/may/25/my-estimation-technique/
-
@jonm@hachyderm.io 2024-05-01 20:53
@polotek@social.polotek.net I read a book on the general subject of expert estimation once that really stuck with me (although I can't find it now). The essence is that estimators (people who estimate) can be useful tools, but they have to be *calibrated*.