Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Voxera842336dSounds like to hard estimates and to strict.
We only estimate in 1 day, a few days or a week.
Even if something is actually just should take an hour its still one day estimate.
Then we allow a bit of over commit for every two weeks.
And if there is time over, we can always dig into backlog on tech improvements that are nice to have.
Of cause, we do not charge by the hour but work on internal solutions of the company.
ltlian196536d@Voxera Oh man, if I had read this during my former job I would have tried applying for a position at your place.
"Use honest estimates, they are only estimates and we need a realistic picture of the workload - but don't sandbag"
"Update the work remaining on the board before client meetings, but don't increase it"
"If a task consists of several predecessor issues, split it up into separate work items, but don't create new tasks as we need to focus on the existing ones"
"This needs to be done before lunch. Don't worry about making it optimal; we need to finally close this and never revisit it"
The result was that everyone tried closing issues before being asked to estimate them, or making best-case estimates that always tripled.
I call it the "Wait a minute" factor. It can take me a few minutes to change a line of code, but wait a minute, this won't work because the BOM preamble isn't handled at this point and we need to overhaul the class library used by 8 other applications.