Sharing is caring!

Overview

Leader (L): “Hey Anna, can you please check on Team XXX burndown chart for the last three sprints, please?”
Me (M): “Sure. What’s the issue?”
L: “Well it looks weird for me, they never fully complete the committed stories but they keep adding more stories the next sprint. Maybe there’s an issue in their Sprint Planning”
M: “Okay, I’ll have a look. There must be some logical explanation behind it”

That was a fragment of conversation between me and my leader.
He knew I will have a Community Of Practice that day and he knew I will address that issue in the Community Of Practice.

Community Of Practice is a once a week session where all Scrum Masters and Product Owners in the organization I work for met to share and learn together.
We usually discuss anything related with our Scrum Team.

What’s The Issue

As I said in the opening part of this article, I addressed this issue in the Community of Practice.

From the discussion, I found some answers why the team did that.

Some of them are:

• “The unfinished stories from previous sprint will only take another day to fix, that’s why we take other stories” – said one Scrum Master
• “Business users want us to deliver this new feature by next week” – said one Product Owner
• “If I don’t give lots of stories for my Development Team, they will work lazy and slow”  –  said one Scrum Master

So what’s the issue if your team adding more stories in the next sprint even when your team never complete the committed stories in the past sprints? Why is that such a problem?

Read the question again and notice I highlight one words…. NEVER!

The problem is not about not completing the sprint backlog, but about the commitment from the team to finish what they agreed on.
Unfinished stories from some sprints probably still acceptable – incident happens – but every single sprint?

Then if you are a developer, you might complain to me and say
“Hey, the Product Owner wants those stories to be in the sprint, we just follow order. Don’t ever say that we don’t commit.”

And maybe the other will say “We spend over night working on the stories, sacrifice our family time to work on this and you just easily tell me that we’re lack of commitment? Are you nuts?”

Chill 🙂
I’m not finish yet…keep on reading…

Speak Up!

When you face that kind of situation, where the Product Owner push the team to have some stories in the sprint backlog during the Sprint Planning, this is the time when Scrum Master must play the role.

Scrum Master must remind the Product Owner that Sprint Backlog belongs to the Development Team.
They are the one who can take the stories from Product Backlog to the Sprint Backlog.

Scrum Values:
Courage, Focus, Commitment, Respect, Openness

As written above, courage and openness are part of the Scrum Values.
The Development Team need also have the courage and openness to speak up if they are forced to take sprint backlog more than they can commit.

Scrum Team must be a safe environment where everyone can work together and not only following order.

Product Owner also need to show some respect when the Development Team raise their concern.

Better Planning

Failing to plan is planning to fail
— Alan Lakein

Back to my opening story, about the team that almost never complete all stories in the sprints and still add more stories in the next sprint which eventually they cannot finish either, what can we do about it?

Here are the suggestions I gave to the Community Of Practice and also the message I always tell my Scrum Team during the Sprint Planning.

Finish your food and add more

It’s like when you tell your child to finish what’s on the plate and add more if she still hungry – rather than taking too much and finally throw the food because she’s full.

I always remind my team about this during the Sprint Planning.

Rather than taking too much sprint backlog, we better finish what we have left, probably adding some new stories – but just enough to be completed within a sprint.
If there are still more time left, Development Team can take more sprint backlog from the product backlog.

Usually my Product Owner already communicate this in the Sprint Planning.
He will say “Okay, let’s say you guys completed all the stories in the next sprint but the sprint is not over yet, you can choose one of these stories (which he already groom and prioritized) to be added in the sprint.”
Then he will add “But remember, take as much as you can commit within the sprint. Don’t force it”

They need to know their capacity and capability.
They need to know their limit.
They need to be mature in choosing what’s right for them.

Challenge The Commitment

After the Development Team take the stories, ask them to ask each other: “Can we commit on these?”

Notice that the team need to ask themselves…between each other.
Not the Scrum Master or the Product Owner ask the question.

They need to commit one to another that the Sprint Backlog belong to the whole team, so if one person need help, the other will support, because it’s a team commitment.

I always do this before they start giving story points. They need to predict the work they need to do and not get biased by the points.

Even though the Sprint Backlog belongs to the Development Team, I always emphasize to myself and my Product Owner that we in “Can we commit on this?” also stands for us.

Scrum Master and Product Owner also need to support the Development Team in completing the sprint.

Look For The Root Cause

Having incomplete stories doesn’t tell the quality of your team.
It doesn’t mean that your team is lack of commitment or not capable.
No need to be frustrated with that.

There’s always a reason behind everything.
So, use the Sprint Retrospective event to discuss the root cause of the incomplete stories.
Once you find the root cause, plan for action item to avoid that from happening in the next sprint.

Conclusion

So which one is better? Looking good or Planning good?
For me planning good is more important.
Planning good will be perfect if it comes also with good commitment of the team.

Remember, failing to plan is planning to fail 🙂