Once we have groomed the backlog and have a relatively clear direction of what should be done in short and long term, how do we decide what to include in each Sprint? Who makes that decision?
It seems like agile methodologies allow the team to decide, but what happens if the team plays things too safe and undercommits?
Slack is essential, but an excess of wasteful idleness is not. True leadership is being able to tell the difference.
The Product Owner prioritizes the Product Backlog, but only the Development Team may estimate stories. The team uses these estimates, along with their estimated velocity, to determine how much work should be accepted into each Sprint.
This only seems like a problem if you take a narrow view. The project has milestones, release dates, and other targets that can be compared against current progress at periodic intervals. If the team is not on track to meet the necessary management targets, then this is good material for organizational dialogues and team retrospectives.
Please note, however, that simply saying the team is under-committing is not the same thing as actually having a team that has large buckets of unused spare capacity. The goal with Scrum is sustainable development, which requires some amount of process slack. It's up to the team and the organization to reach an understanding of how much slack is necessary, and how much is "waste" (e.g. muri, muda, or mura) in the Lean sense of the word.
Remember, 100% utilization is not the goal. If the team is already working at it's optimum sustainable pace, you may need to examine your project's expectations, processes, resources, or scope to find other ways to address your system constraints.
It seems evident that you have a trust issue with your team.
You can't say a team undercommits unless you disagree with their capacity planning. Do you estimate sprint capacity? If you think your teams can deliver more points you can certainly argument that at the planning meeting, however you can't expect the opinion of one person to be considered the "correct" estimate. It's a team effort.
You are part of the team, and have a say.
If you think the team is working inefficiently, or lazy, or simply have concrete ideas on how the team can improve their velocity, the correct place to make these suggestion is a sprint retrospective, and certainly not a planning meeting. I would make sure that retros take place (if they don't already) and that your doubts about the team's efficiency are handled there.
The key to not having this sort of problem is in determining the estimates right. One way to have reasonable estimates is to take estimates from each field expert and reason why he or she thinks so. Thereafter taking all points in consideration estimate a time frame in consensus. For example, if there are three members for taking care of Web-services, all three must explain reasons for estimating the same task. Considering the views from each member, the task is assigned a target time-frame unanimously.
Team decides. Product Owner cannot decide this. Product owner only prioritizes. How does team decide? First time just a guess/common-sense. Second time(sprint) history(20%) + guess(80%). Third time history(40%) guess (60%). And there comes a time when history decides(90%) and common sense(10%). This is the best you could get.
Tip: In the sprint planning meeting keep 1 extra user story ready, otherwise another team meeting might be needed to include a new one in the sprint(if the team finishes faster).
In my opinion, the following factors decides the stories to be included in each sprint.
In fact, it is the combined decision of PO and development team decides the stories to be included in each sprint.
