Testing is not officially the role of the Product Owner. Nor programming and database management...

Relationship building comes along with communication but it’s 2 different things.

In Agile : Working Software Over Comprehensive Documentation

Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development. Agile does not eliminate documentation, but it streamlines it in a form that gives the developer what is needed to do the work.

In Scrum : We must put all the products requirements in the Product Backlog.

The Sprint Review is probably the most important opportunity for capturing feedback but adaptation is not limited to that. The Product Owner is constantly in contact with the stakeholders to identify new Product Backlog items or to refine them.

During the Sprint:

● No changes are made that would endanger the Sprint Goal;

● Quality does not decrease;

● The Product Backlog is refined as needed; and,

● Scope may be clarified and renegotiated with the Product Owner as more is learned.

Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques.

User stories are a fairly common technique for representing Product Backlog Items, but other techniques can be used instead. For instance, a team can use scenarios, use cases, acceptance tests, etc. The Product Backlog might even contain a heterogeneous mix of the above. The Product Owner should work with the rest of the Scrum Team on choosing and optimizing the techniques used to represent Product Backlog Items.

Hardening Sprints are not allowed because the subject of hardening should be continuously address throughout normal Sprints. All Sprints are the same in Scrum. Other options are not described in the framework but are good practices recommended for Scrum projects.

The Developers modify the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Developers work through the plan and learns more about the work needed to achieve the Sprint Goal. The work and scope of work to be 'done' may be clarified or re-negotiated together with the Product Owner if necessary.

Not all tasks are identified in the Sprint Planning; just enough to show what the Developers are going to do in the next few days. The rest of the tasks will be created during the Sprint.

The Developers use the Daily Scrum to inspect progress toward the Sprint Goal and to inspect how progress is trending toward completing the work in the Sprint Backlog.