Development team members under commit and cheat

One of the teams under commits the work and slowly completes all the work by the end of the sprint.

How do you know they are “undercommitting”? What do you precisely mean by that observation?

If you have a team which, for one reason or another, is failing to provide satisfactory product value to stakeholders, then that is the concern which ought to be voiced and which would then need to be solved.

"Undercommitting" is a word that I would never use as a Scrum Master.  A Development Team creates a forecast of what they feel they can accomplish during a sprint.  They have to describe the value being delivered in the potential releasable increment being created.  They also are expected to explain to the PO and SM how they will accomplish that work.  If the PO is accepting of the value that is forecast to be delivered and the team consistently delivers that value then I see no problem

I would have responded with the two questions that @Ian asked.  Because it might be that instead of dealing with the Scrum Team, you should focus your attention on the people external to the team to help them understand Scrum better and how to reset their expectations on how to determine success in Scrum.

Vishal, 

If I understand the question correctly, the interviewer gave you a scenario where he thinks that the team under commits or he thinks that the team can deliver more but they just do not commit too much to the product owner to keep a buffer period in the sprint. To me, this is a traditional project management scenario where the team gives padded estimates to the project manager so that they can get some extra time (for example - 4 hours for a 1 hour activity). 

I think I would first talk to the product owner and ask if the team is delivering as expected. I would also take a look at how the team is estimating their work efforts. 

Thanks

Anuj 

Recently I attended Scrum Master interview and the interviewer asked me he is facing issue in his project. One of the teams under commits the work and slowly completes all the work by the end of the sprint. As a Scrum Master what are your thoughts on solving this issue? Which approach you will use ?

Your first questions should've been: "Where does this under-committment hypothesis come from?" and "How was one able to reach the conclusion there is under-committment? Against what was it benchmarked?"

If the team slowly completes all the work by the end of the sprint then at least you have a good indicator the team is able to complete what they forecasted, and I can reasonably assume the Sprint Goal is constantly being met. If the PO's happy with the value, and things go smoothly, why assume the team under committs? Most people are, by nature, inclined to be truthful/honest; and I wouldn't say there are reduced chances of them deliberately acting (conspiring?) against the company. 

Oh, and one more thing - ever heard of festina lente?

For the sake of the discussions, I'll go through your reasons (though I suggest you read the above to understand why there are no such reasons for under committment)

According to me the reasons can be either one or combination of below points : 

1. Indeed that particular team members are not honest including technical team lead who should is expected to have more knowledge on actual time required to complete particular technical task .

See above. Most people are genuinely honest and love to be trusted.

I don't understand what the technical team lead has to do with here. Are they actually going to work on each and every technical task? Are their words/decisions/estimations the absolute truth? Sure, a tech lead has more knowledge and experience, but if you are to be agile (and even practice Scrum), you need to work as part of a team, not as a lone wolf. The more conversations, followed by agreements or compromises reached, the better off you are.

This reason wouldn't be accurate, imo

2. Almost all team members are inexperienced including technical lead because of which they under commit

It seems only natural, if one's not experienced enough, to be cautious and have a wider angle. So higher estimates. Confidence comes with experience. 

This reason wouldn't be accurate, imo

3. There is no technical expert from client side during sprint planning who can cross question developers

I fail to see why there's a need for this technical expert to cross question developers.right during sprint planning. Exactly who would this expert be? An arhictect? A technical project manager? Why not have this technical expert colaborate with the team before the sprint planning (refinement sessions, workshops, mocks), at sprint planning, during sprint - on a continuous basis? 

This reason wouldn't be accurate, imo

4. Scrum master should have made sure the outcome of retrospective is implemented in successive sprint but somewhere he is unable to do so for xyz reason.

SM is not responsible for making sure the outcome of retrospective is implemented in successive sprint. The entire team owns the improvements, so it's up to the team to self organize.

This reason, too, wouldn't be accurate, imo

If we assume that team agreed on retro that they "play safely" and "undercommit", and still not exactly point WHY they act like that, then I would suspect that there is no courage in team... but it is not a problem inside a team - it is only a symptom of problems outside the team. They can play in defense due to not feeling safe in organization, so maybe you should look / start there?

Thanks to Ian, Daniel, Anuj, Eugene and Piotr.

I read each post carefully and it gave me different perspective to think from .

Really appreciate and thanks again .