As it has been said already, always give yourself a considerable buffer beyond the time that was estimated and that you ought to try to breakdown development into cycles, since you'll get better estimates down the line, given you also have more information available to work with and base your new estimates on the previous work and how it went (it's only indicative... but better than nothing if you are cautious with it)

Accept that tasks won't take exactly the time you think they will. Break them down as much as possible and, if your current methodology allows you, only break down the tasks you'll be working on in the next few weeks (I know, you have to break the others too to get an estimate for the whole project, but honestly you'll be doing nothing more than guesstimates if you haven't started coding the very first few, do it but know that the more further away from the present you estimate, the worse the worse they'll be).

Another golden rule is never to let business estimate times for development tasks. Developers should be estimating time for the tasks they will be doing. They might be optimistic of pessimistic or roughly right, when you come to know them, prefer the last two estimates (in worst case, it's better to underpromise and to overdelivery and you can always help the over pessimistics to tune their estimates). This might be difficult and business people may not always (if any time) buy it and can impose hard deadlines... Just make them aware that there is a risk that they might be entering in technical debt, which as any debt will have to be paid sooner or later, whether that means that a new feature will take longer because the code is a mess or because bugs will pop up since there wasn't time to have proper automated and acceptance testing.

Books I found useful, although I'm not a CTO myself (a bit methodology dependant, sorry): The Art of Agile Development (O'Reilly) Agile Estimating and Planning (Prentice Hall)

thread

thibaut_barrereJan 2011

Here's what I use and recommend:

* Mike Cohn resources were the most helpful to me:

- free presentations around estimating and planning (eg: http://www.mountaingoatsoftware.com/presentations/131-agile-... and others on the same site)

- the "Agile Estimating and Planning" book (http://www.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp...)

- Mike Cohn "Agile Estimating and Planning" course (2 days) was worth taking

* Software estimation: demystifying the black art (http://www.amazon.com/Software-Estimation-Demystifying-Pract...) is a very useful book too

* For lightweight project management tool: I use a mixture of Acunote (for estimating and burndown chart - I even generate my quotes out of it using Ruby and Prawn) and Freckle to monitor the time spent.

I tried many other tools (including Mingle, Pivotal, etc...) but Acunote is the only one that works well for us.

thread

bdbcbcApr 2025

How much time have you invested into it as a skill set ?

Have you read product thinking, the lean startup, agile estimating and planning ?

How do you expect to leverage a methodology if you don’t do a deep dive and become an expert.

thread