Include internal defects into the release notes

How does testing and quality assurance work for scrum? (So that there is very low occurrence of bugs in production.)

Actually, I don't think SCRUM addresses this. SCRUM does not cover all stages of a product/project. SCRUM is mainly about organizing the development itself - the part from "we have an idea for a feature" to "the dev team thinks this is production ready". It does not cover the very first part of a project (basic idea, project vision, finding stakeholders, getting a budget...), and it does not cover the final delivery (deployment, customer feedback etc.).

So if you feel you need an additional stage after the SCRUM team is done, by all means have a separate stage of QA testing, regression testing, certification, whathever, before going into production.

You still get the value of frequent releases because there is something to test and get feedback from stakeholders - but just because you want feedback does not mean you must ship to customers (though this is often helpful). Note that SCRUM speaks of a "potentially shippable product", because you might not actually want to ship the product for various reasons.

Note: Obviously, the disadvantage of a separate QA/testing stage is that it will take longer to actually ship a feature to customers. However, if quality is more important than quickly shipping new features, then that may be the right compromise for you - that is up to the stakeholders and developers to decide.

Many familiar issues that I've also seen at many organizations.

My suggestions are as follows:

• Branch off master for feature branches
• Have QA do the merge back into master and push it
• Release master weekly and tag each release with the release date

That's code and workflow-wise.

The harder parts are likely to be:

• changing the culture
  There are probably a diversity of opinion on what is wrong and why it is. You'll need to have buy in and championing from the highest (relevant) level of the organization. You'll need to explain and sell the advantages of such a slimmed down system. Explain the simplicity and the rapid turnaround. Make sure your (probably) agile process is not just lip service but fully thought out from actual agile practices and, when possible, scrum masters.

• changing the existing workflow You'll need to put together the new workflow and then develop a plan that will let you transition to it.

Other thoughts:

• consider implementing a comprehensive feature switch system that will let your merge in (some) changes but have the features turns on/off through an admin gui.

• in your deliver pipeline rather than finishing the feature and passing to QA, consider involving QA through the design, implementation and testing so that their final ok is a pass thru of well understood and agreed on assumptions. You don't want QA surprised by an implementation and you don't want developers surprise by how QA decides to test.

• Have a weekly release meeting with all parties involved and go thru all the tickets. This can easily be 50-100 tickets. Touch base on each one for: release implications to the business, pre release steps, post release steps, downtimes, etc.