Hmmmm...I appreciate some points brought up by the other answers; others I'm not so sure about. Quotes are mainly from the Scrum Guide as of this writing (any quote from other sources will be noted).
Three pillars uphold every implementation of empirical process control: transparency, inspection, and adaptation.
Transparency means being able to see something (making the implicit explicit), inspecting what is seen, and adapting. The thermostat concept is used a lot in Scrum training.
You set your thermostat to a temperature. The thermostat has visibility into the temperature of the room (metric and feedback). For heating, when the temperature goes below the mark by a certain amount, the countermeasure of turning on the furnace kicks in. When the temperature goes above the mark by a certain amount, the countermeasures are stopped.
What if we covered the thermostat and didn't let it sense the temperature in the room? (Probably gonna wonder why it's not getting warmer in your house.)
Therefore, I tend to err on the side of transparency for everything. And I mean everything. Then, as a coach (no matter the formal role I have - even developers can say, “That’s really not what those data measure.”), I coach and train everyone involved on what's going on. What are the data being collected? Why that data? What does the data mean? What do the data indicate?
At any point in time, the total work remaining to reach a goal can be summed. The Product Owner tracks this total work remaining at least every Sprint Review. The Product Owner compares this amount with work remaining at previous Sprint Reviews to assess progress toward completing projected work by the desired time for the goal. This information is made transparent to all stakeholders.
Various projective practices upon trending have been used to forecast progress, like burn-downs, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision-making.
And, the endnote:
Scrum is free and offered in this Guide. Scrum’s roles, events, artifacts, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Velocity as it is typically practiced is not part of the definition of Scrum - it is an add-on we use to accomplish some form of inspection and adaptation. The definition of total work remaining is something agreed to by the Scrum Team (and the organization as a whole).
Could be a measure of the total number of feature requests (user stories - also not part of Scrum).
Some teams and organizations do not feel that the feature request count is detailed enough; therefore, they turn to story points (not part of Scrum) for more granular detail in measuring work remaining.
All that to say, Scrum, as defined, does not have metrics. Organizations and teams have a desire for data to inspect and adapt. If we're looking at the "wrong" data for the "wrong" reasons, bad things happen. Hence the education and explanation piece being important.
A trainer and consultant I know actually put together a wonderful dashboard to help one of his clients. There are data received from external stakeholders - about the state of the product increment (the only measure of progress - users using something). There are data received from, and which matter primarily to, internal stakeholders. There are data received from individual teams (if you're a multi-team organization), which may matter to internal or external stakeholders...this is usually velocity, burn-ups, and so-on.
If that last one is the only one the organization really focuses on when measuring the success of their organization then I would say they might not be embracing empiricism and transparency.
- External feedback measures may include: Product revenue generation versus cost (return on investment) and customer satisfaction. (The teams might find this information useful and motivating as well.)
- Internal feedback measures may include: Project cost per iteration, time to market, the ratio of new features versus repair and maintenance per iteration.
- Team-level feedback measures: Last, and certainly least, progress - scope, defects, ideal, velocity, and velocity trend.
Is a team (or organization) that goes really fast to deliver a product increment users don't like (customer satisfaction) and aren't willing to pay for (ROI) successful? (Does "velocity" and "burn-ups" measure those things? No. No they don't.)
Is a team (or organization) who burns through money like it's water at a marathon, while taking forever to create a potentially shippable increment, that has no new features successful? (Does "velocity" and "burn-ups" measure those things? Kind of, maybe.)
Is a team (or organization) who completes their forecasted work every Sprint to the level of their definition of done successful? (Does "velocity" and "burn-ups" measure those things? Absolutely. And I have no idea if the team and organization are successful, because we're not measuring - or making transparent - the data necessary to get the whole picture.)
Hope that helps.