Do you estimate and mesure in "value" points?

Most companies estimate and calculate velocity with Story Points

A minor point: Developers provide estimates, not companies. Many Scrum Teams are moving away from points and using flow metrics (throughput, cycle time, work in progress). 

Value points are not a substitute for story points, they have different purposes.

Story points can be used for a few things: to derive velocity which could be used by the Scrum Team in Sprint Planning, by a Product Owner to make tradeoffs between Product Backlog items (by understanding the size), and to forecast a release.

Value points could be used by a Product Owner in a collaborative way to gauge the value of different Product Backlog items. There are various techniques you could use with a group of stakeholders: 35/5 Crowd Sourcing and a Liberating Structure called 25/10 Crowd Sourcing. Therefore points would be used for ordering the Product Backlog.

Remember value are just estimates. Value isn't realized until the work is released, and there are various ways to measure it (e.g.s Revenue, Customer Satisfaction, Feature Usage). Therefore if your goal is to understand value realized measure post release.

Scrum on

Mean to write in the last paragraph "Remember value points are just estimates".

Most companies estimate and calculate velocity with Story Points, but I've seen suggestion to use value points instead. Is any of you using value points? How do you do it, and is it working well? I feel like value points is very hard to implement. I would like to hear your experience.

A Product Owner may use value points to help order the Product Backlog. The purpose of estimation in Scrum is so Developers can get their arms around how much of that work they can take on in a Sprint. How sure can you be that their assessment of this will equate to the value being delivered?

I agree with Ian. In my organization each story is assigned value points by Product Owner and this will help in prioritization of work by the product owner and product management team.

Story points basically used for estimating development work by the development team. Story points came from Lean practices, and it will help to ensure estimation of work by development team in relative fashion without much focus on exactness of estimates.

So the value points and story points server two different and pole apart purposes, and one could not assure that greater value = greater dev story points or vice versa.

As we have work categorization mostly as  "High risk, high value, high risk low value, low risk high value and low risk low value "

So both are different.

Some times 2 story points dev effort can brings more value to business than 8 story points, and hence 2 story points dev US needs to be prioritized based on business value say - $8K.

And 8 story points story can have business value say - $100

So here PO can prioritized 2 story points work in comparison to 8 story point work for upcoming release/iteration/sprint based on organization dev practices.

I feel like focusing on "how much work" can be done in a Sprint is not very useful, you can do a lot of work but it can have no value. But in my experience, everywhere I have worked, the focus is always put on estimating "how much work can be done" and never "how much value can be added".

But in the end, you still gota do both type of estimation (time and value estimation).