What velocity % goal does your team have for a sprint?

Why should a team have a goal related to velocity?

Velocity isn't a part of the Scrum framework, meaning a Scrum Team doesn't need to measure velocity or use it as any part of their process, for retrospection or planning. Velocity, although common, is a supplemental practice that a team could adopt if it helps them.

Even for teams that measure velocity, using it as a goal would be problematic. If achieving a specific target for velocity would be used to assess a team's performance, the team would likely inflate their velocity to achieve "better" results. Instead, the goals should communicate value that the team hopes to achieve during the course of the Sprint.

Velocity is never a target. It's a tool Developers may use for helping gauge how much work they can take on in a Sprint, so a valuable Sprint Goal is met, and complexity is brought under better control.

Goodhart's Law: When a measure becomes a target, it ceases to be a good measure.

Velocity for our team is completely based on past sprints by the team. And it is not compared with any other teams irrespective of departments. The team is coached to be accountable for the delivery. The management does not plan or set target for the team but they should keep informed about the work done. 

I'm going to assume that your measure of velocity is "the number of story points completed during a Sprint".  I say that because it is the typical measurement that people unfamiliar with the Scrum framework use.  It is also one of the least effective measures of velocity. Those story points are a guess made by the developers based upon the information they have at the time they make those guesses.  As work begins, new information is gained that could invalidate those original guesses.  That is why your 3's take different amount of time to complete.  A story point is not earned, burned, or achieved.  They are used as a means for a group of developers to develop a feeling that they have a shared understanding of the work needed and that they feel it can be completed in a single Sprint.  After that, the points are useless. 

As a team works in a domain and together as a group, their estimation will change.  Sometimes it gets better.  Sometimes it adjusts to match what management is expecting them to do. Now, your management has decided that you need to complete 85% of those guesses each Sprint.  How do you think that will affect the guesses made by the development teams? 

Using velocity as a target more often than not will lead to manipulation and it could be worse if it is used to compare different teams. Why not have SMART sprint goals and showcase that as an achievement rather than %velocity achieved.

Agree with the other posts. Just to add, velocity as a target as described, take away a teams ability to self-organise. The team is not in control of their sprint planning, making good decisions and setting achievable goals etc. For a team delivery metric, rather calculate the value produced each sprint. 

A Scrum Master should advocate  in the company for Scrum values and principles like  team self-organisation . 

Historic velocity gives an indication of how much work can be completed in each sprint. So for instance, if a team's average velocity is 100, and they were committing to 50 or 150 points of stories for a sprint I would question why the low or high value this sprint and whether the complexity of stories had been over/under estimated, if it were 80 or 120 I wouldn't be concerned.