The scrum answer is "No we're not, because you don't get to decide what goes in the sprint", but I'm assuming you're doing some dysfunctional form of scrum here?

A "stretch target" sounds reasonable to me - if you complete all the agreed work in the sprint (and have some time to spare), then more work will be loaded in.

There are projects that are important for the business and projects that are important for the PM's ego. Consolidate on one project manager with relatively unimportant projects and cause him to either fail or get the clue. Repeat as required.

How many hours per day is each dev resource allocated for?

Are you asking in general how to manage expectations with PMs (which is arguably too broad to really cover here) or specifically about how you can push back against this habit your PMs have of overloading you with "stretch goals"?

"not doing enough on the business-related story points." Is that emphasis significant? Are you doing the stretch points and not getting other ones done? Or is it just a general "not all the points we assigned were done"?

Stretch Targets are pure fiction. It's just a way for management to say "let's see if we can get these people to work harder", then pretend like the team is committed to doing extra.

@JoeStrazzere Not sure why they are "fiction". It is impossible to size the sprint to keep the developers busy all the time and be confident the stories are done. Stretch targets give developers who finish the committed stories early opportunity to contribute instead of sitting idly and waiting for the sprint to finish.

@NemanjaTrifunovic developers doing scrum would never "sit idly", they would just go looking for more work when the sprint was going quicker than initially planned.

@Erik Exactly. And "stretch goals" are what the developers are supposed to look for after they are done with committed stories.

@NemanjaTrifunovic key to that sentence being "after they are done", not by adding them to the initial sprint. They're not "stretch goals", they're just the next most important thing, that you look for if (and only if) you happen to be done faster than planned.

@Erik: Agree. If they are added to the sprint, they are not "stretch" anymore, but "committed".

@Lilienthal - Yes business-related story points are important. There is tech debt points, bug fixes, and other tasks that have points, but the business does not get value from. The business value portion of the sprint could be low, and the other tasks high in a sprint. The business does not like to pay for those sprints.

The PM may be thinking "How do you know your team isn't capable of a velocity of X+1 unless you occasionally take on X+1 points and see?" Some teams fall into a comfort zone where they keep doing X points, even though they are capable of doing more. Although perhaps I am giving the PM credit for more scrum knowledge than they seem to have.

How often does this occur? If it's an isolated situation during one sprint, your team should be able to live with it.

You only commit stories into a sprint that you believe you can reasonably finish by it's end. If you somehow find some extra time for whatever reason (tasks took less time, tasks are unexpectedly blocked, whatever), then you pull things into the sprint from your backlog. The project manager will likely have already prioritized some items in the backlog for this reason and future sprints. Because as things look now, it appears that you're only completing XX% of your sprint commitments, which won't look good at first glance to management.