- completion of sprint goals? Does the Product Owner need help articulating requirements, creating stories in the backlog, or prioritizing work? These are all questions that a ScrumMaster needs to be attuned to in order to streamline communication between the team and the Product Owner, while helping them to maintain a high level of productivity.
- How is the team doing? Apart from the impediments and updates that team members explicitly report during daily stand-ups and other meetings, a ScrumMaster can glean a great deal of information about a team just by observing how its members interact. Are they comfortable with one another? Do they crack jokes and enjoy one another's company? Or do they keep to themselves? Do certain team members not get along with others? Examining-and addressing-the psychology of the team is another way that ScrumMasters can spur teams to do their best.
- How are its engineering practices doing? A ScrumMaster can do the team a lot of favors by reminding them at every opportunity of the value of agile engineering practices and thorough testing. Many agile techniques would appear to sap a team's productivity. (For instance, a common misconception of pair-programming is that it assigns two developers to do the work of a single person.) However, these techniques actually build testing and, consequently, risk mitigation into every step of development, which allows teams to accelerate cycle time considerably.
- How is the organization doing? ScrumMasters can even work together to help the organization itself-a much broader definition of "team," certainly-evolve into a more productive and efficient entity. Especially in larger Scrum installations, which often require a Scrum-of-Scrums management architecture, ScrumMasters can meet with one another frequently to discuss those problems that impact the organization as a whole and develop plans to resolve them. Of course, in situations such as these, it is not only the ScrumMaster's team that benefits from their work, but the entire organization.
The Team and the Product Owner
As previously stated, the Product Owner negotiates with the development team to determine what work it will attempt to complete in the next sprint. However, the Product Owner also helps the team maintain a state of productivity by remaining available to answer questions and further clarify acceptance criteria. By now, we understand that Product Owners communicate product vision and goals to team members in the form of PBIs during the sprint planning meeting, but what does that process actually look like?
Most Certified Scrum Trainers (CSTs) would agree that PBIs should be written in user story format. The formulaic wording can be a great guide rail when teams are struggling to articulate exactly what needs to be built and for whom. A simple way to explain user stories is that it is a formulaic phrasing that captures a product increment, using the following format: "As a [role], I want [function] so that [rationale]." There have been numerous books written on the topic and the one that most everyone points to is Mike Cohn's book User Stories Applied. However, PBIs and user stories are not enough. Next, we will need to discuss the single trickiest thing to master once your teams are up and sprinting: defining what it means to be "done." To me, "done" might mean that a piece of software works on my laptop, but "done" to my team member may mean that the same application works for 2,000 simultaneous users. The definition of ‘done' is where scope creep can kill you. It is where individuals who like to gold-plate things can end up in the weeds for days or weeks, and where sophisticated Product Owners can