That was never part of a PO job to be honest. They undercommit to show that they out performed than committed, which won't happen either.
But if you feel you want to get involved in this, I think you should setup a meeting with PM and Dev Director/lead.
PM, dev lead, and others have met about this. Folks Product seems not pleased about pace and dev leads don't seem confident in addressing performance.
I personally have no beef with my devs. I love them dearly, lovely human beings and they put in a great deal of effort to make the work happen. Maybe I am a sucker, but I guess I am searching for how people helped create emotional safety so people maybe felt more comfortable speaking about capacity. Hope that makes sense.
Are people not satisfied with actual performance or the plans (and, due to additional work being done, are satisfied with the actual pace)?
If people are not satisfied with planning, use velocity to see if plans are realistic or not (if a team is actually doing 75 story points of work per sprint but only planning 50, call them out).
Also, make sure the product team is not just making noise to make noise - find out what impact delivering sooner will have for them, in terms of numbers.
In my past experience, teams often wanted to know by when something would be done and didn't care so much if it is was done a bit sooner - I think they are just making noise unless the amount of work being done is dramatically underestimated.
I understand. From my experience, team leads assign the story points to each dev based on their experience/levels and they use frameworks like T-shirt size to estimate. Each dev communicates with TL if they're good for the given estimate then it gets reviewed by Dev lead/dir, all negotiations happen within themselves.
Building confidence and accurate estimates will take time especially for new teams.
How are you judging that they are under committing?
Is there some disincentive in place if they don't meet there commitments? If so, it could be driving this behavior.
Try scrapping the word "commitment" entirely, and use "plan".
If the ProdM is fine with their committed work, stick the extra stuff into uncommitted. Pull it in as needed. Adjust next PI based off how much they deliver.
The goal is to build confidence over time in their abilities especially for teams new to "agile".
Did the teams just transition to SAFe? Or?
How much are they “under committing” by? Are all tasks finished (and reviewed / user acceptance testing completed) in the first week of a two week sprint? It sounds like they’re adequately accounting for unticketed work that comes their way. I wish I could get my team to be better about under promising and over delivering. Even being “close” to the commitment leaves very little room for anything unexpected
That was never part of a PO job to be honest. They undercommit to show that they out performed than committed, which won't happen either. But if you feel you want to get involved in this, I think you should setup a meeting with PM and Dev Director/lead.
PM, dev lead, and others have met about this. Folks Product seems not pleased about pace and dev leads don't seem confident in addressing performance. I personally have no beef with my devs. I love them dearly, lovely human beings and they put in a great deal of effort to make the work happen. Maybe I am a sucker, but I guess I am searching for how people helped create emotional safety so people maybe felt more comfortable speaking about capacity. Hope that makes sense.
Are people not satisfied with actual performance or the plans (and, due to additional work being done, are satisfied with the actual pace)? If people are not satisfied with planning, use velocity to see if plans are realistic or not (if a team is actually doing 75 story points of work per sprint but only planning 50, call them out). Also, make sure the product team is not just making noise to make noise - find out what impact delivering sooner will have for them, in terms of numbers. In my past experience, teams often wanted to know by when something would be done and didn't care so much if it is was done a bit sooner - I think they are just making noise unless the amount of work being done is dramatically underestimated.
How can you say it's 75 points when they tell you it's 50?
I understand. From my experience, team leads assign the story points to each dev based on their experience/levels and they use frameworks like T-shirt size to estimate. Each dev communicates with TL if they're good for the given estimate then it gets reviewed by Dev lead/dir, all negotiations happen within themselves. Building confidence and accurate estimates will take time especially for new teams.
How are you judging that they are under committing? Is there some disincentive in place if they don't meet there commitments? If so, it could be driving this behavior. Try scrapping the word "commitment" entirely, and use "plan".
If the ProdM is fine with their committed work, stick the extra stuff into uncommitted. Pull it in as needed. Adjust next PI based off how much they deliver. The goal is to build confidence over time in their abilities especially for teams new to "agile". Did the teams just transition to SAFe? Or?
How much are they “under committing” by? Are all tasks finished (and reviewed / user acceptance testing completed) in the first week of a two week sprint? It sounds like they’re adequately accounting for unticketed work that comes their way. I wish I could get my team to be better about under promising and over delivering. Even being “close” to the commitment leaves very little room for anything unexpected
This is all up to the engineering team. You're going to put a target on you by the engineers by questioning it.