My first suggestion would be to correct your terminology to improve communication, both internally and externally. You use terms such as "Scrum Master", "Sprint" and "Sprint Review". These are Scrum terms. Scrum is a well-defined process framework with specific roles, responsibilities, and events. It contains rules and these are defined in the Scrum Guide. If you do not use Scrum, you should not call what you do Scrum and you should not use the Scrum terms because it only confuses people. Note: It is perfectly fine not to use Scrum or to take the good ideas of Scrum (or any other process or process methodology) and create your own process.
Then I would look at your estimation method. To get back to the terminology, I would recommend you stop calling what you do "history points". Like Scrum, there are commonly accepted definitions of "history points", and this is not a fixed duration. That said, if the time estimates work for you or if you have a reason why you need to use them, you must continue to use them.
When planning an iteration, I would consider three things. First, consider the total capacity of the team. If you have specialists, work on cross training, so that little work needs to be done by one person to allow an estimate of the ability of the entire team. When estimating, do not consider that the work will be done by an expert but by an average member of the team. If the expert gets it, it will be done perhaps faster. If someone else receives it, you will have a better chance of getting closer to your estimate. Finally, never plan 100% capacity. There is always overhead – holidays, unplanned holidays, meetings. I would have to find my sources, but the most productive organizations reach about 80% (using your estimation scheme, ie 4 "scenario points" per iteration week per person, assuming that 39, there is no vacation or vacation planned) and many organizations are closer. at 60-70% (3 "points" per iteration week per person). As a general rule, all work must be completed in one iteration, a single unit of work must not exceed 6 points in a two week sprint (which represents a capacity of about 65% per year). nobody – a fairly average organization). Also be sure to leave some of your capacity for production issues when planning. You can use historical data to understand it.
For tracking measures, it does not matter what you do as long as you are consistent. If you do not evaluate production problems, you will probably see a break in the burndown process as one or more people stop working on estimated and planned problems and production problems. If you estimate production problems, your remaining work will increase and then be exhausted as work progresses. In either case, I would not update the scheduled burndown line. My personal preference is to estimate all the work – new feature, modified functionality, bugs versus production. I would also recommend not giving a default value for production problems, but asking the team to provide a reasonable estimate for each of them.
To re-estimate, again, it does not matter as long as you are consistent. My recommendation is never to re-estimate. If the job has not been completed during an iteration, it retains its initial estimate for planning the next iteration. In project management, it is common to assign a "credit" only for the completion of the tasks performed. In some cases, a small percentage is assigned to the started tasks. It's often incredibly difficult to tell how much real progress has been made – if you think you have a solution, tests may reveal that another problem has been introduced.
At the end of each iteration, you should organize two types of events. The first, which Scrum calls a "sprint review", is product or service oriented. You look at what you have achieved with key stakeholders and discuss not only what you have accomplished during the iteration, but also what your next goals should be for the next iteration. The second is an internal reflection on how the team works to find ways to improve interactions between the team and stakeholders, between team members, or ways to improve the way of working. (the processes, methods and tools used by the team). ).
I would also start by looking at why you can not change things, for example by asking one of the developers to play the role of facilitator and coach, or why you have to estimate in time instead of trying to do it. another unit. I would highly recommend to most organizations to hire a dedicated person to understand and improve the processes, methods and practices of the engineering teams. This person must understand the environment in which the team and the organization evolve, as well as various methods, and can accompany the organization and the team on the way to the organization. continuous process improvement.