I love the "uncertainty curve" concept you described, James. I think it's a great mechanism to handle timelines and "estimations".
It reminds me a bit of Shape Up, in particular, the chapter: "Estimates don't show uncertainty". As you mentioned, the key is to start with a forecast until you can remove uncertainty from the equation.
Excellent post! I completely agree that forecasting is a better approach to communicating expectations with the business. It also looks nice on quarterly roadmaps which we all know execs love.
I have still found value in the individual engineers and teams going through the estimation process. It helps them work through some of that uncertainty upfront by thinking through the risk areas and dependencies.
I agree that estimation is always important, even if it is highly inaccurate. In fact, sometimes a forecast is a great external-facing tool to use, when inside the team you can still stick to specific dates if it helps.
Love the simple yet concise the uncertainty factor. I would like to add a certain section on managing expectations of non-tech leaders of throwing more software engineers. Just throwing more software engineers at a project during a sprint might seem like the answer to a tight deadline, but it can backfire. Here's why:
1. Merging code written by different engineers can be complex and time-consuming, leading to more bugs and delays.
2. Without clear ownership of tasks, multiple engineers might unknowingly work on the same feature, wasting time and resources.
3. New team members might not have the same level of understanding as existing members, creating knowledge gaps that slow down progress.
4. With great power comes great responsibility. So with more code comes more testing. The increased testing workload can strain resources and impact deadlines.
5. Feeling like a cog in a large machine can decrease team morale and motivation, leading to reduced productivity.
6. Unclear ownership of tasks can lead to confusion and delays as engineers wait for direction.
7. Communication and collaboration can be more difficult for geographically dispersed teams, impacting project efficiency.
8. If new engineers require significant training to get up to speed, this can eat into valuable development time.
So, let's ditch the "throw more at it" mentality and focus on efficient workflows and the right team for the job. Clearly define goals and break down tasks into manageable chunks. This reduces context switching and ensures everyone is aligned.
Thank you for the comment! The only way you can get round that is to accept collectively that scope is flexible, and some features might not make the cut.
I recently finished reading “How Big Things Get Done”. It talks about why 99.5% of huge projects are either later, over budget, or under deliver on expectations (IT projects included).
Often in our world, those dates are given with barely any planning. While you can’t foresee everything in advance, a through planning process can reduce the uncertainty and narrow the range from the beginning.
I love the "uncertainty curve" concept you described, James. I think it's a great mechanism to handle timelines and "estimations".
It reminds me a bit of Shape Up, in particular, the chapter: "Estimates don't show uncertainty". As you mentioned, the key is to start with a forecast until you can remove uncertainty from the equation.
Thanks for the comment!
Shape Up is indeed a good framework. I wish I used it more for real.
Excellent post! I completely agree that forecasting is a better approach to communicating expectations with the business. It also looks nice on quarterly roadmaps which we all know execs love.
I have still found value in the individual engineers and teams going through the estimation process. It helps them work through some of that uncertainty upfront by thinking through the risk areas and dependencies.
Thank you Dustin! I appreciate it.
I agree that estimation is always important, even if it is highly inaccurate. In fact, sometimes a forecast is a great external-facing tool to use, when inside the team you can still stick to specific dates if it helps.
Love the simple yet concise the uncertainty factor. I would like to add a certain section on managing expectations of non-tech leaders of throwing more software engineers. Just throwing more software engineers at a project during a sprint might seem like the answer to a tight deadline, but it can backfire. Here's why:
1. Merging code written by different engineers can be complex and time-consuming, leading to more bugs and delays.
2. Without clear ownership of tasks, multiple engineers might unknowingly work on the same feature, wasting time and resources.
3. New team members might not have the same level of understanding as existing members, creating knowledge gaps that slow down progress.
4. With great power comes great responsibility. So with more code comes more testing. The increased testing workload can strain resources and impact deadlines.
5. Feeling like a cog in a large machine can decrease team morale and motivation, leading to reduced productivity.
6. Unclear ownership of tasks can lead to confusion and delays as engineers wait for direction.
7. Communication and collaboration can be more difficult for geographically dispersed teams, impacting project efficiency.
8. If new engineers require significant training to get up to speed, this can eat into valuable development time.
So, let's ditch the "throw more at it" mentality and focus on efficient workflows and the right team for the job. Clearly define goals and break down tasks into manageable chunks. This reduces context switching and ensures everyone is aligned.
Thanks for the detailed comment! There's a lot of wisdom in there.
Excellent article James !
This approach works but only if the assumption you've so correctly stated in the last para holds true.
How do you deal with it if the executives are pressurising the teams to "put a specific date on it "?
Thank you for the comment! The only way you can get round that is to accept collectively that scope is flexible, and some features might not make the cut.
I recently finished reading “How Big Things Get Done”. It talks about why 99.5% of huge projects are either later, over budget, or under deliver on expectations (IT projects included).
Often in our world, those dates are given with barely any planning. While you can’t foresee everything in advance, a through planning process can reduce the uncertainty and narrow the range from the beginning.
I hadn't heard of that book — added it to my list. Thank you.
It's surprisingly fun to read. Based on your writings, I'm pretty sure you'll enjoy it too :)