Your team ships an arbitrarily 10 points per sprint by doing what they think is right. The same team could ship an arbitrarily 20 points per week. 10 is the _true_ cost of building a healthy system. There is not a lot more to do for good team, honestly, at that point. Management can't say anything
This sort of thing is only useful for managers who don't understand what is going on. Since they are unable to look at code and understand it, 'points' give them a semi-opaque substitute.
If management trusts the team, it is not necessary.
If you understand what is going on, you will get rid of points altogether, and look at the git log from time to time.
If you are a leader, and not just a manager, you will help your programmers improve their skill, so over time you spend less and less time managing them. Your programmers will appreciate it because with greater self-management comes greater happiness and job satisfaction.
The points are (also) an estimating mechanism. They let you estimate a new task in points (effort measurement) instead of hours (time measurement), and then use history to predict a likely timeframe based on your typical rate.
The extra layer of indirection helps to account for uncertainties in the task, imprecision in the estimate, and chaos (in the scientific sense) in how long individual tasks take relative to aggregated historical metrics.
Totally. Some teams want the points though So I let them have it.
But I just set the principles I explained above for the points to have an actual meaning.
