Missed estimates are not an opportunity for blame, but rather an opportunity to inspect your process and adapt it to fit the requirements of your organization. The Product Owner, the Scrum Master, and the Development Team must all work together to learn from the failed sprints.
It seems like the entire Scrum Team is working under some misconceptions. Let's see if we can't clear some of them up.
[The] team...has missed every sprint commitment through the first 4 by between 40 and 60% measured by points.
Nope. Based on what you're saying, the team has missed the first four Sprint Goals by 100%. A user story is either done or not-done, and a sprint goal is either met or not met. There are no shades of gray.
The team continues to say, that it is OK and that the stories were mostly done and they'll just split and move stories forward.
Nope. As the Product Owner, it is your job to review the Product Backlog after each sprint and determine how (or even if) missed stories should be re-prioritized, and what stories should be placed at the top of the Product Backlog for the next sprint. In other words, nothing is "carried forward" unless you place it back at the top of the backlog.
I have asked for root causes of the problems and the team is pushing back hard saying that management needs to trust the team.
Nope. Blaming the team is not constructive, but asking the team to inspect the estimation or delivery process when there's clearly a process problem is extremely reasonable. In fact, it is part of your responsibility as the Product Owner to engage the Scrum Master and the Development Team in the various Scrum meetings to identify and remove roadblocks to successful project delivery.
I don't know what the root cause is here, but you need to involve the Scrum Master and the rest of the Scrum Team to find out. Some possibilities include:
- The Scrum Team is doing a poor job of estimating story sizes, and taking on more than can fit into a sprint.
- The Scrum Team as a whole may not be articulating a Sprint Goal that is both achievable and clearly defines what stories are essential to the current sprint.
- Retrospectives or other forms of inspect-and-adapt are not being performed to identify why the process is not working.
- The process is not respecting the time-boxed nature of the sprint or the Scrum framework.
Transparency of the process is essential to the success of any agile implementation. The team is not entitled to tell the Product Owner to mind his own business when stories accepted into a sprint are routinely incomplete at the end of each sprint.
Closer Collaboration Required
Based on what you have not said, I'd wager good money that part of the problem is that you either do not have a dedicated Scrum Master, or you do not have a Scrum Master who is able to provide the education, feedback, coaching, and process adaptation necessary for a successful Scrum implementation within your organization.
Even if that isn't the case, I certainly think you need to collaborate more effectively with the Scrum Master. Whatever deficiencies your team may or may not have, the relationship between the Product Owner and the Scrum Master is one of the most important aspects of the Scrum framework. Don't neglect it!