How to encourage the commitment on a sprint for a team

Question

The biggest problem I have right now is the team is unable to commit on the stories and tasks planned during a sprint.

For example, we wanted to implement a new database, which is very complex and we have a number of possibilities. We knew we had to find out how we could implement the database, and searched for awhile, but after three weeks during the sprint demo we had nothing to deliver and it was communicated only at that moment.

They don't seem to comprehend that they have to deliver what was talked about in the sprint planning, that they have to talk about the fact that they can't deliver something during the daily stand ups, and that they can change or not respect the scope of the sprint.

How do I get them to understand that they should commit on what they planned during the sprint planning, so that they are more capable of planning their next sprint and respect what they planned?

• I tried putting up a visible burndown chart with post-its but it takes so much time to write all the user stories...
• Force them as a team to create the tasks during the sprint planning (before the last sprint, I would be showing them jira on a projector and a team member would tell me what they would do, while the others would not be listening).
• I'm also trying to put shorter sprints (from 3 weeks to 2), but I'm receiving a lot of challenge from my team lead: he says at 2 weeks they are not able to deliver anything, but in my opinion they are not able to deliver enough in 3 weeks sprint also.

Thank you,

Stef

Answer 1

You can't possible force people to commit to something. Commitment should be, by definition, a voluntary act. I believe that it is possible to do something and I know I'll do my best to do this thus I commit to achieve the goal.

If you think about forcing people it's not a commitment any more - it's just getting the monkey off my back. Want to hear that this will be ready in 2 weeks and not going to leave me be? OK. Here, I said this. Happy now? Just don't tell me it is a real commitment.

What you can do to get what you want is:

• First, learn why they avoid any commitments. They might have been punished for not keeping their commitments in the past so they learned to avoid them. Or they just might not understand why it is important for the rest of the organization. Or something else. Unless you know what is the root cause of this situation it would be hard to act reasonably.

• Second, help them to understand why you, and others in the organization, need this commitment. Explain how it affects planning, decision-making, allocating people and resources etc. Try to put them in your shoes so they will see why it is so important for you.

• Third, address any problems the team has with committing to anything. If they don't want to be punished when they fail, assure them they won't be. Explain that the goal is to have them doing their best and that you understand that everyone fails occasionally. If there's some other reason address it as well.

• Fourth, try to teach them to achieve their goals step by step. Start with small and easy-to-achieve commitment so they see they can do it. You also set up a good track-record this way. If your goals at the moment are too ambitious or too challenging either look for something smaller/easier, or cut them. Maybe not a full report on possible data bases but just comparing a set of crucial features, or performing a set of basic tests etc.

• Fifth, communicate frequently. If at the end of the week you learn that nothing has been done it is your problem as well as others'. It means that you don't communicate frequently enough or the quality of communication is low. How could such thing slip through all the stand-ups?

• Sixth, avoid, by any means, forcing people. This way you aren't going to end up with a real commitment at all. Quality of information you get from the team will be poor as well. You won't be able to plan anything basing on "commitments" in such situation.

Answer 2

To begin with, I would like to point out that in the newest Scrum Guide by Ken Schwaber and Jeff Sutherland, we are not talking about commitment in a way where we ask the team to deliver a certain quantity of features, but rather to commit on deeper meanings like the quality of these features or working with business people on a daily basis. It's a subtle, yet meaningful difference. Suggested reading: Is commitment dead?

As for the situation you are in, I would like to ask if you, as a ScrumMaster, have done everything to avoid this situation? Were you aware of the situation but hoped for the team to find a solution before the deadline? Or have you actively tried to find someone (a DBA for instance) that could try to answer any technical questions (or the Customer for any business questions) the team might had in order to clarify what is their best option? Was there any reason why your Customer was informed quite late about the problems and not before?

As a ScrumMaster, your job is to do that. Not to simply be there on Scrum's artefact meetings and remove any requested impediment, but also the one the team cannot communicate to you specifically. You need to be aware of what's happening and try to make it better or simpler.

Teams will fail to deliver some features, that's bound to happen in every company. The best approach we can have when a team fail is to inspect what happened and adapt to prevail. And I hope the ScrumMaster of this team will also try to inspect and adapt.

I know I may seem harsh over you, but I lack more information on the reason why the team failed (and I know for sure the problem is not only on how you handled it). Reading on how they are acting on your Sprint Planning, I would be tempted to say you are not dealing as a team but a collective of individuals. You may want to try to have some team building activities with them to begin with. Suggestion further readings: The Five Dysfunctions of a Team and Overcoming the Five Dysfunctions of a Team.

Once you'll have a team, maybe things will become easier.

Answer 3

It sounds like you're not getting the feedback that you need during your daily Scrums. Status on critical deliverables should always be communicated through out the Scrums.

When first adopting Scrum, teams tend to over commit, and will scale back to a more realistic amount of work each sprint as they learn what their true velocity is. The team should get a better handle on how and what they can commit to with each sprint retrospective.