What are the most common reasons for a scrum team failing to meet their commitments?

What are the most common reasons for a scrum team failing to meet their commitments?

Welcome to part 2 of our scrum master interview questions series where John McFadyen answers common questions asked of scrum masters in interviews and client engagements.

This is an interesting question for an interview, so let’s focus on the more common reasons for teams failing to meet a sprint goal or product goal, based on my experience.

Lack of a sprint goal.

The most common reason for a scrum team failing to meet their sprint goal is mainly because they simply don’t have one. The team just haven’t identified and committed to a sprint goal and as such, they haven’t got a north star to guide them, and they just push deliver stuff.

Technically, you can’t fail at something if you haven’t got a goal but I’m sure you get the idea.

In practice, a scrum team need something valuable to aim for. They need something that pushes them out of their comfort zone and inspires them to stretch with each iteration.

The sprint goal plays an important role in empowering the team to do just that.

In the scrum certification programs I lead; we often have a conversation about this.

• Does the team need a sprint goal?
• Is it important for the team to commit to achieving an overarching goal for the sprint?
• Does the team need to identify goals and objectives in conjunction with a sprint backlog?

In my opinion, it is incredibly valuable that they do, but I have also witnessed teams who focus on a random selection of work – from the product backlog – that just needs to be completed within the sprint cycle.

As a scrum master, you’re best served focusing on the reality of life.

Sometimes, there is simply a bunch of things that need to be delivered and there is no cohesive, overriding reason for it to be done. It just needs to get done.

Is it imperative to create a sprint goal in this scenario?

In my opinion, no, if the team know what needs to be delivered and their primary focus for the sprint lies in meeting those commitments, great, they still have something to aim for and it is easy to measure whether they have succeeded in delivering everything they committed to.

In my experience, teams who operate like this on a regular and consistent basis tend to struggle.

If it’s a once-off event, great, no problem. If the team seldom identify a sprint goal and lack purpose, you are going to witness an underperforming, below average team.

So, for me, the number one reason why teams fail is because they don’t have a combined sense of purpose and they don’t have inspiring sprint goals that encourage them to collaborate and create effectively.

If you’re struggling to identify a sprint goal, simply have a conversation with the team and identify what the most valuable item for delivery might be, and potentially just make that your sprint goal.

If all else fails, what is the one thing we could still deliver that would make the sprint a success?

We might identify three things that must be delivered, no matter what, and when we achieve that we can confidently say that the team have met their sprint goal.

If you can’t identify something within the work itself, look outside the product and identify what you would like to achieve as a team.

• What do you value as a team and what do you want to see more of?
• What do the team want to become and what measures would indicate success?
• What kind of behaviours do we want to encourage and why are they important?

And so forth.

You are going to make behaviours, skills acquisitions, or mastering of process a sprint goal.

It empowers the team to reach for a stretch goal and acquire a sense of purpose and achievement despite having a product goal. It allows the team to measure their progress and use sprint retrospectives to identify how they can improve as a team.

Sprint planning failure.

The second reason why a team might consistently fail to achieve great performances lies in their inability to plan effectively.

In my experience, scrum teams fall into 2 camps when it comes to planning.

• Camp 1: Teams who get in and out of sprint planning as soon as possible.
• Camp 2: Teams who invest time and effort into planning as effectively as possible.

Camp 1: Teams who get in and get out of sprint planning as soon as possible.

These kinds of teams tend to walk into sprint planning, pull several items from the sprint backlog and commit to delivering those items to the product owner.

There isn’t much thought, discussion, or planning involved.

It is simply a case of making snap judgments about the work and delegating that work as quickly as possible.

• There is no discussion about why the item matters to customers and end users.
• There is no discussion about how best to tackle the problem or create the product/feature.
• There is no decision-making around who is best positioned to solve the problem.
• There is little to no understanding of how that item aligns with the big picture or product goal. Teams don’t understand how this optimizes for the whole product.

Often, this leads to the team tripping up in the sprint.

It also leads to mediocre work, rather than great work, and reinforces a culture of low performance.

Failing to take the time to do due diligence and gain a greater understanding of why the work matters, how it serves customer and end user requirements, and what great looks like means that the team are never going to improve or deliver great work.

These teams consistently fail to solve the most valuable problems and fail to create the most valuable products and features. Things that could have been identified during planning, simply weren’t identified, and this causes knock-on effects that spiral into poor performance.

Addressing sprint planning failure is one of the more effective ways to help this kind of team make solid gains and rapidly improve.

Camp 2: Teams who invest time and effort into planning as effectively as possible.

Investing time and effort into planning is great, but in poor performing teams, you find that they invest too much time in trying to figure out how to get things done and fail to plan effectively because they are caught up in focusing on too many items and too many nuances.

A month-long sprint has an 8-hour timebox for planning, yet these teams will invest multiple days in planning and fail to get going with the most valuable work.

Often, they take on more work than they can realistically deliver and incorrectly estimate how much time and effort is required to deliver the work.

It seldom happens that teams are great at sprint planning when they form as a scrum team, but you do want them to learn from each iteration, and progressively improve their sprint planning skills.

They should be using the sprint review to get feedback from customers and product stakeholders, and they should be using sprint retrospectives to identify where they can improve and where they need to make a concerted effort to improve.

If they are consistently failing in the sprint planning process, that needs to be a strong focus for the team to improve with each sprint.

The scrum master and product owner should be actively working with the team to help them identify the most valuable work, in order of priority, and to help them determine what most matters to customers – and why it matters a great deal – to ensure the team are planning effectively.

Camp 2 are in a better position than camp 1 because they have done some planning, and even if they end up planning 7 of their 12 items before running out of time in the sprint planning event, they still have a better chance of delivering value to customers and product owners than camp 1.

So, if you’ve got camp 2 on your hands, work with the team to select a few items that truly matter and effectively plan those out within the sprint planning timebox. As the team improve, you can take on another item here and there and build momentum on delivering what the team commit to.

With each iteration, the team are going to improve and customers are going to be increasingly more satisfied with what is being delivered in each sprint, leading to great team morale and a commitment to continuous improvement.

So, for me, these would be the most common reasons for a team failing to meet their commitments.

About John McFadyen

If you are interested in becoming an agile coach and value mentored, coach-driven skills development in your journey to mastery, visit our Growing Scrum Masters website.

For more information on John McFadyen, connect with John on LinkedIn at https://www.linkedin.com/in/johnmcfadyen/.

If you like the idea of becoming a scrum master and want to achieve internationally recognised and certified accreditation as a scrum master, visit our Certified Scrum Master (CSM) course page.

If you are already a scrum master and want to upskill to a more advanced level of knowledge and agile coaching capability, visit our Advanced Certified Scrum Master (A-CSM) course page.

If you have several years’ experience as a scrum master and want to validate and certify your professional skills, visit our Certified Scrum Professional Scrum Master (CSP-SM) course page.

#agile #agilecoach #agilecoaching #agileprojectmanagement #agileproductdevelopment #agility #businessagility #scrum #scrummaster #scrumtraining #scrumcertification #scrumalliance #agilecentre #johnmcfadyen #coach #coaching #certifiedscrummaster