In an Agile organization the Scrum Master role requires not just a solid understanding of the Scrum framework, and also a strong understanding of Agile and DevOps principles, as well as a hit of project management know-how. The Scrum Master as a coach leverages their knowledge and experience to help the team know how to leverage these principles to drive improvements in delivery.

In a Scaled Agile organization (specifically referencing SAFe) we occassionally consider the need for a team to follow Kanban rather than the more common Scrum. This decision makes sense in many cases, but comes with special considerations for how to handle integrating a Kanban team into a SAFe Release Train that has primarily been using Scrum.

In an Agile team, be it Scrum or Kanban, we want to be Ready before we start work on any Backlog Items. Confirming that we are Ready helps us convey confidence to our Product Owner that the team will be able to achieve their goal. The team defines what it means to be Ready, shares that with their Product Owner for transparency, and leverages it with every Backlog Item.

In an Agile organization we find our stakeholders often seeking some understanding of when a work product will be “Done”. We could be talking with our Product Owner about any kind of Backlog Item, be it a User Story, Defect, new Feature, or even a full Epic.

In a Sprint we commit to being Done when we select Backlog Items and set a Sprint Goal during Sprint Planning. How well we Refine our Backlog Items is key to meeting that commitment in-sprint, and the Acceptance Criteria are one way we capture that refinement.