Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> but suppose I assign you a task that I think will take two days in my limited understanding

Why would the manager be the one making estimates? That's a task either for the team, if applicable, or for the implementer.

edit: I work from home, every sprint we have a planning meeting where we do the estimates together, my manager isn't even involed in it.

Only if we're expecting to exceed an estimate by 20% do we contact the project manager (not my manager) so we can figure out how to proceed.

How we work: we have a bunch of tasks available that we create during the sprint planning and we pick them as we have time, some may be marked as priority. My manager only hears from me if I'm ever blocked for some reason and need him to either get in touch with the person that is blocking the task or similar, otherwise we don't.

For us at least the manager is someone who enables us to spend our time productively, generally speaking he'll have no idea what I'm doing most of the time. I guess you could say we're self-managed.



Assuming that "the "manager" knows his 'stuffs', should know that TaskA requires 5 hours, and TaskB requires 1 hour. Now to that add a 20% for interruptions, emails, etc.

With my team(s) I (almost) always knew (more or less) the time for various tasks.

I was also expecting any feedback/'negotiation' to happen at the time of task assignment OR as soon as someone can see that deadline is at risk.

I know that Tasks from Tasks vary, but hey, this setup requires knowledge from both parties AND trust.


What I've often experienced is the manager estimates what he wants to happen (typically fairly arbitrary or based on company goals) then the team kills themselves trying to accomplish the timeline because they don't like to fail. This is great for short term productivity but long term leads to attrition and spitefulness from the team. I'm not saying it's not possible, but make sure what you think is happening, is happening (good sustainable estimates vs. constant crunch time estimates). Of course, situations warrant crunch time, but I've seen departments in a constant state of crunch just by the nature of their sprints. The saying goes, you can't sprint a marathon.

Also, depending on the organization, a 20% buffer seems on the low side. If you can guarantee zero distractions throughout the day, outside of 1 or two meetings a week, 20% is probably ok.

FWIW, if the developer makes the estimate, he is more likely to live up to it, because it's not just some number someone pulled out of their ass. I'm not saying that's you, I'm just saying how I've seen it happen time and time again. I like to think I give good estimates, but like you said, it's a negotiation and if a dev says it will take longer, it will take longer. They most likely know the codebase way better than some manager does.


> should know that TaskA requires 5 hours, and TaskB requires 1 hour.

I contest this. This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation: a project asks for an estimate and we give it based on how much we feel it's going to take, there is no negotiation; either the project manager accepts it or reduces scope and we make a new estimate, my manager is uninvolved.

I suspect this might be a work culture thing: in my country managers aren't timekeepers, their responsibility is making sure we have all the conditions we need to be productive and be "invisible" otherwise.


> should know that TaskA requires 5 hours, and TaskB requires 1 hour.

> This assumes the manager is also some sort of software engineer plus I don't understand why would there be any negotiation:

We have whole methodologies based on the premise that we (software engineers or managers) are incredibly horrible at estimating software.


the project manager will know the timeline breakdown while your manager may not.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: