Creating Tasks for Scrum Masters

According to The Agile Manifesto: “The best architectures, requirements, and designs emerge from self-organizing teams.” As a Scrum Master, your job is to help your team become self-organizing, and thanks to the Scrum framework, you have what you need to help the team own their tasks in the project.

The Product Backlog

Everything a Scrum Team needs to work on is in the Product Backlog, which is simply a list of the things users and customers want from the product, grouped by epics, features and user stories. A popular format of recording a product backlog item (PBI) is writing down user stories: “As a (user role), I want to (describe action here) in order to (describe value or desired output here).”

A good PBI is understood by everyone: they know what its objective is, what the desired outcome is, and what level of complexity and feasibility it has. The team can opt to use an online tool to manage PBIs or a physical board with swim-lanes – whichever is more manageable. Ensuring that these characteristics are followed will help the development team have a better picture of what they need to do.

Sprint Ceremonies

While the Scrum Master can coach the team at any point during the project, the Sprint Ceremonies are the most important activities in the timeline and also the best venue for managing the work to be done. This is where the team inspects the work done and adapts to changes for upcoming work. While each ceremony has different purposes, they all have an impact on what tasks the team will accomplish.

Sprint Planning

The first part of Sprint Planning is used to identify what to put into the Sprint Backlog. This is where the Product Owner identifies the Sprint goal, scopes what backlog items to include, and prioritizes the Sprint backlog from the most important to the least important. The Product Owner must be able to clarify what the functionality is and why they’re valuable. Acceptance criteria should also be discussed so that the team will know what to meet in finishing PBIs.

The second half of Sprint Planning is where the team discusses how to finish the Sprint’s product increment. Tasks for each PBI are identified, and because tasks are never assigned to a Scrum project, each team member picks tasks for themselves. More experienced team members can take the technically challenging tasks, while less experienced ones can choose simpler tasks or be mentored for the more difficult ones.

If not yet done during Product Backlog prioritization, the team also estimates the complexity or amount of time needed for each PBI. One way to estimate PBIs would be to use Poker Planning, where everyone votes for the agreed Story Point, a number relative to the complexity of the PBI at hand. The total Story Points in a Sprint indicates the total effort needed to be given. While the Product Owner may choose not to take part in this session, it’s beneficial to have him around in case the team needs to clarify or renegotiate the scope.

Sprint Review

The Sprint Review is the ceremony primarily used for inspecting the product increment of a Sprint. Each PBI is demonstrated to the Product Owner (along with other customers, if available) and feedback is taken for each PBI. If not done during the Sprint, PBIs are assessed if they meet the Definition of Done or if they still need to be worked on. The feedback gathered can also be used to come up with future PBIs, which, in turn, will create more tasks for the team.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: