A window into my life. Managers are obsessed with when it will be done and I discovered why. The managers had already told execs when the feature would be done without consulting the team and the team had not even seen the requirements. The justification I hear for this behaviour is "Those estimates were made by experts who know the product and feature architecture better than developers" I pleaded with the Program Manager if he does that again it's his ass, not the team's!
It is an interesting observation, thanks Barry. Although I think not all of them do this, I bet that's the reality of many companies. What was the reaction of the PM to that?
SO many times Ive seen all the anti-patterns you mention Maria! This is why the #noestimates movement gathers pace - because it really doesnt matter how accurate your estimates are. The whole point is that they are a conversation starter - they are not meant to be accurate!!! The example of 2 outliers is a good one - someone says 3, most of the team says 8 & another person says 13. It's "why the 3 & 13?" - "are we missing something?", "are we making things overly complicated?". Or...when the team decide the story is a 21 - "That feels too big - shall we look to split it down into a number of stories THAT EACH DELIVER VALUE?" To me, helping identify when a story is too big, or as a conversation starter is the whole point of estimation. I get a sinking feeling every time I hear a Manager say "we need to calibrate the teams' estimation" or "lets benchmark Team Donut against Team Croissant, based on their story points" Estimating in Story points is there to support refinement - it's not a measure of success. Focus on the VALUE!!! Great video Maria!
This is awesome, thanks for taking the time to write this, GT! And I agree with all that you are saying. Estimations in Story Points serve as a conversation starter and arriving at a shared understanding of what needs to be done. I would even say that looking at the velocity and other metrics dashboards can also give us a sense of how the team is doing and if there are any patterns we should investigate. E.g. a steady decrease in velocity or some strange peaks. But that's just one of many inputs for retrospective and the continuous improvement. As you say, we absolutely shouldn't compare the teams' estimations and rank them against each other. That's a management anti-pattern :)
A window into my life. Managers are obsessed with when it will be done and I discovered why. The managers had already told execs when the feature would be done without consulting the team and the team had not even seen the requirements. The justification I hear for this behaviour is "Those estimates were made by experts who know the product and feature architecture better than developers" I pleaded with the Program Manager if he does that again it's his ass, not the team's!
It is an interesting observation, thanks Barry. Although I think not all of them do this, I bet that's the reality of many companies. What was the reaction of the PM to that?
SO many times Ive seen all the anti-patterns you mention Maria! This is why the #noestimates movement gathers pace - because it really doesnt matter how accurate your estimates are. The whole point is that they are a conversation starter - they are not meant to be accurate!!!
The example of 2 outliers is a good one - someone says 3, most of the team says 8 & another person says 13. It's "why the 3 & 13?" - "are we missing something?", "are we making things overly complicated?".
Or...when the team decide the story is a 21 - "That feels too big - shall we look to split it down into a number of stories THAT EACH DELIVER VALUE?"
To me, helping identify when a story is too big, or as a conversation starter is the whole point of estimation. I get a sinking feeling every time I hear a Manager say "we need to calibrate the teams' estimation" or "lets benchmark Team Donut against Team Croissant, based on their story points"
Estimating in Story points is there to support refinement - it's not a measure of success. Focus on the VALUE!!!
Great video Maria!
This is awesome, thanks for taking the time to write this, GT!
And I agree with all that you are saying. Estimations in Story Points serve as a conversation starter and arriving at a shared understanding of what needs to be done.
I would even say that looking at the velocity and other metrics dashboards can also give us a sense of how the team is doing and if there are any patterns we should investigate. E.g. a steady decrease in velocity or some strange peaks. But that's just one of many inputs for retrospective and the continuous improvement.
As you say, we absolutely shouldn't compare the teams' estimations and rank them against each other. That's a management anti-pattern :)