No extra roles and titles are recognized in Scrum because it blocks self-organization, collaboration and accountability.

The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

The Product Owner is also accountable for effective Product Backlog management, which includes:

● Developing and explicitly communicating the Product Goal;

● Creating and clearly communicating Product Backlog items;

● Ordering Product Backlog items; and,

● Ensuring that the Product Backlog is transparent, visible and understood.

The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

The following 12 Principles are based on the Agile Manifesto:

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2 Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

3 Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4 Business people and developers must work together daily throughout the project.

5 Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7 Working product is the primary measure of progress.

8 Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9 Continuous attention to technical excellence and good design enhances agility.

10 Simplicity–the art of maximizing the amount of work not done–is essential.

11 The best architectures, requirements, and designs emerge from self-organizing teams.

12 At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.

The Developers are required to conform to the Definition of Done. If there are multiple Scrum Teams working together on a product, they must mutually define and comply with the same Definition of Done.

Product Backlog management includes:

Clearly expressing Product Backlog items;

Ordering the items in the Product Backlog to best achieve goals and missions;

Optimizing the value of the work the Developers perform;

Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

Ensuring the Developers understand items in the Product Backlog to the level needed.

Sprint Planning is timeboxed to a maximum of eight hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Only the Product Owner can cancel a Sprint.

Kanban does not replace or discount any part of the Scrum framework. It is designed to enhance and expand the practices of Scrum. Implementing Kanban assumes the reader is operating a process using the Scrum framework. Therefore, The Scrum Guide applies in its entirety.

For reminder : The Sprint Goal is created during the Sprint Planning event and then added to the Sprint Backlog. As the Developers work during the Sprint, they keep the Sprint Goal in mind. If the work turns out to be different than they expected, they collaborate with the Product Owner to negotiate the scope of the Sprint Backlog within the Sprint without affecting the Sprint Goal.

Managed conflicts can be very helpful to the project. The Scrum Team must always keep a constructive mind though.

You can have more than one release per Sprint, if needed.

When you use continuous integration and have a Definition of Done that covers everything, you can practically release the product at any time you want (think of it as a typical DevOps environment). The Increments that are created at the end of the Sprint are NOT the only potentially releasable products; they are just packaged and named like this, to be used for receiving feedback at certain intervals.