Timeline for When subordinate gives the stakeholders a lower time estimation
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 27, 2021 at 17:26 | comment | added | Hellion | @JoryGeerts Consider if the dev says "it'll take 1 hour" and the stakeholder says do it. 3 days later the stakeholder asks "where's my result?", the dev says "Your hour is scheduled for next month." The dev's estimate may be 100% accurate and correct but the stakeholder is not going to be happy. | |
| May 27, 2021 at 11:05 | comment | added | Fildor | @JoryGeerts "The stakeholder didn't ask "when will it be done", they asked "how long will X take"." - In my experience, when non-devs ask "How long will X take?", they actually mean "By when will X be done?". But all of this is irrelevant. If my superior states "It will take X amount of time" in a meeting. I won't say anything different except maybe, that "this optimistic estimate will put some pressure on the dev team"... you never know what kind of politics are going on if boss-man obviously overestimates an effort. | |
| May 27, 2021 at 8:44 | comment | added | Jory Geerts | Re "but he's not aware of the full picture. We have other work to do as well." The stakeholder didn't ask "when will it be done", they asked "how long will X take". Anything that is not directly related to X is irrelevant, so using this to explain why the dev gave a different number from the manager will only make the manager look bad, wouldn't it? | |
| May 27, 2021 at 7:55 | comment | added | Fildor | Our Dev-Team has a golden rule - the only one without exceptions: "WE DO NOT GIVE TIME ESTIMATIONS TO STAKEHOLDERS!" We have it as a framed sign in the meeting room. Kind of like a "No Credit. No pants = No Service" sign in a bar. And whenever somebody asks "How long will ..." we point to it. Now how does that work? We ask a "when do you want it finished and when do you absolutely need it finished?" date. Then we give the PO a "Go or NoGo", maybe together with a "if we do it, X and Y will come later, Z will not be able to be finished before its deadline - still do it?" | |
| May 27, 2021 at 7:04 | comment | added | A C | @GwynEvans The dev's level of experience makes no difference for this answer; it's based on the subordinate dev relationship as described in OP's question. | |
| May 27, 2021 at 6:13 | comment | added | Gwyn Evans | The concern I have with this and other answers is that the dev isn’t described as “a junior dev”, which the question implies but rather “one of my leading developers”, which to me, potentially changes the situation. | |
| May 27, 2021 at 2:14 | comment | added | user34687 | @a.t. High initial estimates give leeway for the team to adjust downward with no negative consequences. Low estimates do not give the same leeway to adjust upward. | |
| May 27, 2021 at 2:13 | comment | added | user34687 | @a.t. estimates are not fungible things, but management thinks they are - if the junior dev is giving significantly lower estimates in public than the rest of the team, then all they have actually done is undermined the rest of the team and committed them to delivering. Unless, of course, the only person going to be working on anything the junior developer estimates is ... the junior developer. And then they sink or swim on their own - they have to meet their estimate. But they have still committed the team to delivering on time because thats the estimate they gave in public. | |
| May 26, 2021 at 23:29 | history | edited | Kilisi | CC BY-SA 4.0 |
added 139 characters in body
|
| May 26, 2021 at 23:04 | comment | added | Frank Hopkins | @StephanBranczyk yep even without that, many devs, myself included have a tendency to look at the abstract problem and once they found a nice elegant solution for that, the implementation seems easy and fast, but one almost always overlooks the nitty gritty details then on ad-hoc intuitive estimates. Estimation is tough work, ad-hoc estimation requires lots of experience and good self-control. Independent of attempt to impress. Especially contradicting with an apparent easy solution is dangerous because one may overlook something and then the easy solution doesn't work out and it falls apart. | |
| May 26, 2021 at 19:52 | comment | added | Stephan Branczyk | @a.t., Because an eager less experienced member of the team will always try to impress the higher-ups by giving shorter estimates. To that person, it's a dopamine rush. And such a dopamine rush in one person could easily cost the rest of the team 12-hour workdays, including having to work on weekends and holidays, only have to the big boss be disappointed when the project is finally delivered much later than what he remembers having been told initially. | |
| May 26, 2021 at 18:42 | comment | added | a.t. | Perhaps a bit naive but it seems like pretending to be a uniform body on something that can be "so" subjective obfuscates the certainty with which estimates are generated. I can imagine giving a first estimate of the order of magnitude of the timeframe may benefit the client, and A "public" 1 minute exchange between two people dis-agreeing might convey a more accurate confidence in the estimate. Can you explain why this is not preferred in your experience? | |
| May 26, 2021 at 14:36 | comment | added | user126252 | Nailed it. Perfect. | |
| May 26, 2021 at 7:55 | history | edited | Kilisi | CC BY-SA 4.0 |
added 22 characters in body
|
| May 26, 2021 at 7:50 | history | answered | Kilisi | CC BY-SA 4.0 |