I am reading this and my team has collected a lot of historical data like how many story points finished, how many planned, how many unplanned tasks, bugs, sick leaves and what not. But we are still nowhere if having good estimations in the sense of someone takes that to plan when feature X can be shipped to a customer. One thing based on the data that we collect that correlates very well with performance of the team is developer happiness. We ask every dev every Retro about their current feeling.
So, one question I would ask before “what is an estimation” that is “why do we need estimations?”
Estimations will not make you faster. It will not enable you to deliver anything earlier or better. So why not just work on the thing with the highest business value? Maybe, when in doubt one could use a rough estimation (X is bigger than Y) to decide on what feature with the same business value to start with?
I agree. I think that when the estimation relates to "When can we release this feature to customers?" but there's no other contingency on it than that, it really makes it difficult to find a compelling reason why you would need an estimate. Generally, you would think that what truly matters is exactly what you said: what has the highest business value?
There are a few times I have seen teams trying to coordinate with each other and communicate with various stakeholders where the estimate is meaningful as far as allocating resources and ordering work at the layer above. Think of a situation where a team is needed to support the efforts of several other teams, and thus they want to know if team A will need them only three weeks or six weeks, because team B will need them in three weeks.
A lot of the time such situations can be avoided if teams are self-sufficient, but in reality there are situations where that is not possible, e.g. when you are resource-constrained and trying to work lean.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I am reading this and my team has collected a lot of historical data like how many story points finished, how many planned, how many unplanned tasks, bugs, sick leaves and what not. But we are still nowhere if having good estimations in the sense of someone takes that to plan when feature X can be shipped to a customer. One thing based on the data that we collect that correlates very well with performance of the team is developer happiness. We ask every dev every Retro about their current feeling.
So, one question I would ask before “what is an estimation” that is “why do we need estimations?”
Estimations will not make you faster. It will not enable you to deliver anything earlier or better. So why not just work on the thing with the highest business value? Maybe, when in doubt one could use a rough estimation (X is bigger than Y) to decide on what feature with the same business value to start with?
I agree. I think that when the estimation relates to "When can we release this feature to customers?" but there's no other contingency on it than that, it really makes it difficult to find a compelling reason why you would need an estimate. Generally, you would think that what truly matters is exactly what you said: what has the highest business value?
There are a few times I have seen teams trying to coordinate with each other and communicate with various stakeholders where the estimate is meaningful as far as allocating resources and ordering work at the layer above. Think of a situation where a team is needed to support the efforts of several other teams, and thus they want to know if team A will need them only three weeks or six weeks, because team B will need them in three weeks.
A lot of the time such situations can be avoided if teams are self-sufficient, but in reality there are situations where that is not possible, e.g. when you are resource-constrained and trying to work lean.