How should report to the manager given the uncertainty in the estimation and planning?
I am a developer who get a little bit chance to serve as scrum master last year. I understand that in scrum, planning and estimation is an evolving process. However, I believe a lot of companies are actually mixing scrum with other styles. For instance, in my company, the managers are always expecting an concrete plan. I can understand the managers need the confirm answer to feel securited. But sometimes I feel difficult to handle this situation. If I tell them with confidence(which I actually not) they might get disappointed in the end. If I tell them the risk, they also feel I am not doing good job and everything lost control. And they are more happy to those colleagues that are always say confidencely that everything will be done even without ask the development team. Maybe the managers need more information about how scrum works, but as a developer, I don't have much chance to talk to the manager, and it is impossible for me to 'educate'them. Any suggestion about how to handle such cases?
Although it's not necessarily a concrete plan, the outcome of Sprint Planning is a selection of work that the Development Team believes they can accomplish over the course of the Sprint, a Sprint Goal that can guide and focus the team on the most important outcomes or objectives of the Sprint, and a plan to do the work.
If you have a stable team, after a few Sprints worth of work, you have information that can be used to forecast the work that can be done in an upcoming Sprint. If you know the tolerance for risk of the organization, you can consider this when computing how much work to plan on achieving during the upcoming Sprint, using the past work and team's capacity.
It's somewhat concerning that your organization's leadership and management isn't listening to risk. Risk is inherent in any kind of engineering or product development effort - there are a lot of unknowns that need to be discovered as the work progresses. Scrum and the other agile approaches are, among other things, designed to reduce the risk and minimize stakeholder's exposure to risk.
One of the responsibilities of a Scrum Master is to teach and coach stakeholders about agile methods and Scrum. If you aren't able to do this, the organization should seek more guidance on the application of lean and agile, perhaps from outside coaching at all levels of the organization. Agile requires shifting mindsets for everyone - traditional ways of working have been found to have problems and the agile methods seek to resolve many of the problems and improve quality.
How is the Product Owner accounting for risk and uncertainty to management stakeholders? How wise does he or she think it would be to attempt a concrete plan?
.find_in_page{background-color:#ffff00 !important;padding:0px;margin:0px;overflow:visible !important;}.findysel{background-color:#ff9632 !important;padding:0px;margin:0px;overflow:visible !important;}
Not sure if this would help and you should be careful with it but do you know how often the confidentially provided plans are accurate? One of the big benefits of agile is that it makes problems obvious. Find a way to surface that without pointing fingers. Start tracking your plans against what actually happened and make it visible somewhere, possibly a piece of paper taped to the wall of your workstation. Start by making your own efforts very transparent and maybe others will follow suit. Agile was born from the fact that confidentially set long term plans were seldom met or if they were met the product was not what the customer needed at that time. This could be an opportunity to coach when you lead by example. Give an estimate followed by the statement similar to "Everything I just said could, and most likely will, change once I start doing my work and start to deal with the current unknowns. The information I uncover may lead to a shorter or longer duration but it is impossible to know at this time." Then make sure that you provide daily updates to what you have completed, what you have learned and any impact you can see to your original estimate. Even if this is done via email to the entire team and management.
You said that you don't have many opportunities to actually coach but in your shoes I might start this initiative with asking why your company felt that agile was the right way to operate and what was expected from it. And you mentioned Scrum Master but nothing in what you described is really Scrum. From your question, I read a bunch of inconsistencies with any form of agile that I know.
... but as a developer, I don't have much chance to talk to the manager, ...
I have all kinds of bad feelings about that statement whether you are doing Scrum, agile or just plain waterfall. I hope that the manager you speak of is not your direct line manager. If that is the case then I can certainly see why agile is not in use because there is no communication occurring. I have been a manager many times in my past and I felt it imperative to talk with my staff as often as I could.
Start tracking your plans against what actually happened and make it visible somewhere, possibly a piece of paper taped to the wall of your workstation. Start by making your own efforts very transparent and maybe others will follow suit.
To add to what Daniel Wilhite said, you should research Monte Carlo estimation, and look for ways to use past project metrics to support such an estimation approach.
Your management may be more open to such "ballpark" and "likely %" type estimations, especially if they are derived from past performance. Data and transparency are always good for Scrum Masters to gather and promote.