While I agree with some of the core reasons behind this change, the concept of commitment is still key to a successful Agile team. Teams and individuals should know what to commit to and embrace a culture that promotes growth through honestly examining failures.

We tell our customers that once we commit to a sprint the team will deliver on that commitment. We can do that because we’re able to build strong relationships between our product owners and team, we are not afraid to admit when we fail and figure out how we can be successful, and we work hard to build an understanding of the specific user-focused value of a backlog item during refinement.

Commitment happens at different levels and between different parties during a sprint. The team’s first commitment to the Product Owner is to deliver, within a certain time frame, working code that generates user value. The team can express what they are comfortable committing to, which encourages them to work closely with the Product Owner during refinement to maximize communication and understanding.

The daily scrum meeting represents a point when a team member commits to the team on the work they will accomplish, forming an accountability relationship that can help build overall team success. Team members are accountable to each other and should build each other up while speaking honestly and thoughtfully. When a team member doesn’t meet their daily commitment (it happens!), the team works with each other to learn how to grow in this area.

Just because we hold our commitments as important doesn’t mean we don’t occasionally fail. But when we do, we address it during our retrospectives and collaborate with our Product Owner to determine how to move forward and be successful. This process has worked well for us so far.

But what are some common causes of failing a sprint? Here are some questions to ask so that you can minimize the risk of a sprint failure:

Are your acceptance criteria too specific?

Acceptance criteria should be value-focused and allow room for negotiation, but not so vague that the team isn’t sure what to do. The team should focus on delivering value, and the Product Owner should focus on communicating what users consider valuable. Failure to do this could force the team to contract negotiation, focusing on checking items off a to-do list instead of working with the Product Owner to maximize customer value.

Are you acceptance criteria too vague?

Freedom to negotiate doesn’t mean you shouldn’t work to understand what your Product Owner wants and what defines success in their mind. If you are consistently ending a sprint and not meeting your commitment, your team may not be spending enough time in refinement to gain a mutual understanding of how to create value for your user.

Are you focused on “gold plating” and not user satisfaction?

Every line of code ever written will be deleted one day. It’s easy for talented developers to focus on writing the best code possible, but this sometimes causes us to lose sight of delivering value to our customer. The trick is finding the perfect balance between maintainable, low tech-debt code and pristine, “perfect” code. Just because this can be a difficult balance to find doesn’t mean we shouldn’t look for it, because it drives ability to meet commitments. If you’re failing sprints because you can’t finish the development, or the development is too hard because of fragile code, your developers should work to resolve this problem.

Is your team afraid of failure?

It’s hard to know how to improve if you don’t acknowledge areas of weakness. I firmly believe development is one of the most difficult things we try to do as humans. It’s basically people that speak Latin working with people that speak Klingon trying to write something in Spanish. It is unbelievably difficult, and we are going to get it wrong. That’s OK! We will fail, but failure is not the end of the process. And when we do fail, we should take a sober look at what we got wrong, learn from it, change what we’re doing and move forward.

Whether you believe a team commits or forecasts work to be done during a sprint, the same things must happen to be successful:

• The team commits to deliver value to the customer;
• The customer and team commit to collaborate and work together to make sure this happens;
• The customer and team commit to learn from failure and get better over time.

If these things are in place, you will have a successful team. If not, you will struggle with Scrum regardless of how you view the team forecast.