7

Don't even say your initial time estimate/guess out loud. It will probably become your deadline, and you probably assumed that most things would take a reasonable amout of time.

Bonus: Try to get onto projects that you think you can get interested in. Once on a project try to keep interested in it's success.

Comments
  • 1
    Keep your original estimate to yourself and make at least three times your estimate as the official one (Scotty principle).

    If they buy it, you're fine. Most of the time you'll get at least half of the estimate cut off anyway.
  • 0
    Estimates are dumb and pointless
    We've already invented velocity charts
  • 1
    My 2 cents are that you should always ask: ”Why must we estimate at all?”

    If you could release at any time, my opinion is that you should say: fuck estimates!
    So many orgs are just needlessly inventing imaginary timeconstraints upon themselves

    If the assigment is: do it until it’s done.
    Then why even bother with the guesstimates
  • 0
    This lesson was quite hard for me to learn. Me and my PM came from the consultant world and became employees at a public website.

    At first we went along with the regular sprints that involved time estimates.
    But after a few months we realized there was no need to estimate anything.

    We did what needed to be done in the backlog:

    If we thought some task was a standout in terms of taking too long compare to it’s value, we brought it up for discussion.
    Everything else just rolled on and took the time it took cause it needed to be done.
  • 2
    BUT There are cases where release deadlines are strictily necessary; such as
    * you can only release a few times per month/year. Then you should really prioritize what should go into every release
    * your release has to sync with some other team’s release
    * consultancy work where your short lived contract (sadly) depends on a sales rep being able to convince the customer of everything in the next monthly release

    However, many time these constraints do not exist and too many orgs are so brainwashed by SCRUM (sprints and burndown charts) to even realize they are just inventign imaginary constraints
  • 0
    Yes, estimates are pointless. Here we really need them only for sales to have something to base a price on (which will be cut off by 30% minimum anyway).
    When we get the order we will have to do it, no matter how good the estimate was. But time/budget based on the original estimate is not an issue here, luckily.
    The issues with deadlines are based on other stupidity
  • 0
    Fucking idiots (managers) at my current place decided to have 'mid-sprint demos', effectively shortening the development time. WTF ? And these idiots have other ideas after the demo..
  • 1
    How do you track velocity without assigning value to tasks or features though? Time estimates are surely useless, but other evaluations of tasks seem just as arbitrary to me. Thoughts anyone?
Add Comment