Depending on how you define the term, I have been on at least five and as many as seven agile software teams. Two were brilliant; two were poisonous; the rest were just flaky. A big part of the poison stems from not understanding how to do agile estimation.
This is part of a message that showed up on a mail list I lurk on:
Since the list name has the word "Scrum" in it, I will assume this person is a Scrum Master.
The first misunderstanding here is to know that all estimations are wrong. But when we do estimation in an agile way, we find over time that as we come to share a consistent idea of what a "point" means, that our estimations will be consistently wrong in the same way. This allows us to plan with a high degree of accuracy.
So if you have a agile team that consistently estimates 20 points per sprint and achieves 10 points per sprint, then the capacity of the team is 10 points, and 10 points is the figure you need to use for planning purposes.
The term "meeting their sprint commitments" bothers me a lot. For one thing, insisting that a team complete more stories than the capacity of the team can support is a well-known recipe for technical debt and poor quality. For another thing, it's not "their" sprint commitments, it is our sprint commitments. Finally, I object to describing this situation as "a problem" for the team to look at.
Remember what the job of the Scrum Master is? The Scrum Master has only one job on the team: to remove impediments. If there is a business reason to achieve a consistent velocity of 15 points instead of 10 points, then the Scrum Master should examine the situation for impediments to remove, not try to force the team to meet some sort of imaginary capacity in order to satisfy the requirements of what is essentially an old-style Gantt chart.
This is part of a message that showed up on a mail list I lurk on:
I'm working with a team that does great work. They are skilled and
work well together.
They also average about 50% or less in meeting their sprint
commitments. And don't seem to mind.
"There's a lot to do we just didn't get to it all."
"We'll do that in the next sprint."
"Yeah, that's not working yet."
These are the kinds of statements during the sprint or in the retrospectives.
How do I help this team look at the problem to solve it, instead of
just living with it?
Since the list name has the word "Scrum" in it, I will assume this person is a Scrum Master.
The first misunderstanding here is to know that all estimations are wrong. But when we do estimation in an agile way, we find over time that as we come to share a consistent idea of what a "point" means, that our estimations will be consistently wrong in the same way. This allows us to plan with a high degree of accuracy.
So if you have a agile team that consistently estimates 20 points per sprint and achieves 10 points per sprint, then the capacity of the team is 10 points, and 10 points is the figure you need to use for planning purposes.
The term "meeting their sprint commitments" bothers me a lot. For one thing, insisting that a team complete more stories than the capacity of the team can support is a well-known recipe for technical debt and poor quality. For another thing, it's not "their" sprint commitments, it is our sprint commitments. Finally, I object to describing this situation as "a problem" for the team to look at.
Remember what the job of the Scrum Master is? The Scrum Master has only one job on the team: to remove impediments. If there is a business reason to achieve a consistent velocity of 15 points instead of 10 points, then the Scrum Master should examine the situation for impediments to remove, not try to force the team to meet some sort of imaginary capacity in order to satisfy the requirements of what is essentially an old-style Gantt chart.