how do you deal with teams that don't want to commit work to a sprint?

Here is some things that I think that can be done to help in this scenario.
The stories can be broken down ( SM shall work with PO to get this done). this will allow for better estimation and hence improve ability of the team to commit to something
Also appears that there is no consensus between team members and hence SM can improve this by some team building activities.( I am just going through the book Team Building toolkit ) appears that the team is in the forming phase.
Also SM can re emphasise the reasons behind making team commitment when talking to a team.

If you read the scrum guide it talks about the team forecasting what they can deliver in the sprint, not committing to it. It is a key word and one that might make the difference.
It seems that some of the members of the team have their hesitations about what can get delivered - either they do not know enough (thats okay) or they know something which means they will either make it or will not be able to block it. Help them understand you're after the honest answer, rather than anything else. You want to discuss as a team and get to the bottom of why people think/feel the way they do.
You could also try this -
ask the team "If we are sat here at the end of this sprint and we have done all of the stories we forecast today, what will have happened to make it so?"
then you can ask them "if we are sat here at the end of this sprint and we haven't even come close to the stories we forecast today, what will have happened to make it so?"
This allows the team to play devils advocate on their own.
You can then discuss each item on each list - try and make the things in the 'delivered everything' section a reality and items in the 'not even close' get out of the teams way.
More often than not the 'not even close' will reveal what organizational impediments exist that need to be escalated to a higher level and have more debate on.

Encourage the team to be open & honest - this increases transparency and will make inspecting & adapting so much easier at the end of every sprint or whenever the team feels like they need to adapt!

Remember it is all about empiricism!

+1 with Tim, it is all about empiricism !
At best, team members can give you some estimate (forecast or percentage) but nobody can say "I'm 100% sure the job will be done by 2 weeks", else they are just lying in order to please you.

> Half the team is optimistic it'll get done, the other half thinks
> it won't get done (and looking at velocity I don't think it'll get done).
>
> What should a PM do in this case? We're all new to scrum/agile.

In Scrum terms, the immediate problem isn't whether or not the work can actually be done. The immediate problem is that the team is unable to collaborate and reach an actionable consensus before a Sprint even starts. What then, are the chances of the team being able to work together *during* a Sprint in order to deliver a successful outcome?

You should see this as an early opportunity to improve those collaborative methods. Things to consider include:

- the technical skills that team members have right now
- how skills can be shared, such as by pairing
- whether or not team members share the same view of risks and dependencies
- whether team composition is appropriate

If all the user stories are created based on the "INVEST" principle, I don't see the reasons why the teams can't commit to the deliverable. I suggest that the team use 5 "why" to find the root cause of this reluctance:

- why aren't we confident of completing these stories by next sprint even they have been estimated?
based on the agreed answer, you can continue to ask why to find the root cause, so as to help the team solve their problems/concerns.

my 2 cents

An excellent question and a common dilemma for organizations transitioning to scrum. Here is what I have heard and experienced as good advice.

You can't jump 50 buses with a scooter... no matter how steep the ramp.

Management can exert pressure and make demands, but unless the team is lazy or distracted, execs might as well pressure the sun to rise faster. The only purpose for their pressure in scrum is to move things up the backlog, which it seems you have done.

Scrum is based on Empirical Process Control. This means using what we know (the past) rather than using what we don't know (the future) to make forecasts. The Scrum answer is in your statement that looking at velocity (known past), you don't think they can make it. If there is consensus on effort, and the effort required over two weeks is more than has been done in two weeks, then this stunt won't go well. Those who are optimistic are relying on what they don't know, (predictions about what they think they can do over a period of time) instead of relying on what they know, velocity (what they have been doing over a period of time).

The team should not commit.

Now the nuance is that a scrum team should not focus on "pressure" from management but on priorities from the product owner. The team does not commit to management that they will do x by end of sprint; instead, they commit to each other that they will bring x to done within the sprint. Those who are optimistic may feel they can implement some emergency procedures that have worked in the past. Maybe there is a higher velocity for those times. In that case, the team may commit to each other that they will give it a shot.

There is great advice from posters here.

If x is too big, then try to break it down into smaller pieces of functionality and value. If the feature must be all or nothing, consider the scaled agile framework. x is a feature that can be delivered in a release cycle, and it's child PBIs are delivered in sprints. Some can be for internal users. As a developer, I need this database schema so that I can create x for the end user.

If this is a frequent problem, then perhaps the team needs to transition to longer sprints. Up to a full month may be required for organizations that frequently build large features.

If the real problem is time and management has to have x in two weeks, drop the NOS or switch bikes. Just don't play Evil Knievel if those options are unavailable.

Hope these ideas help you as much as they have helped me.

Best,

Josh