this process, the Product Owner determines which product backlog items (PBIs) the team will tackle, but how those items are completed-i.e. how the team decomposes them into tasks-is the team's decision. In short, tasks are defined and used by the team. When Product Owners engage in task-level management, it can lead to a perversion of Scrum's fundamental principles and result in dysfunction associated with traditional project management such as:
(a) "Employee resource balancing";
(b) Product Owners assigning tasks based on perceived skill sets; or
(c) Product Owners trying to match reality to an ‘ideal' sprint burndown chart.
Because Scrum values team self-organization, it asks the Product Owner to respect the team's ability to determine for itself how to complete sprint goals as they relate to task management and, otherwise, stay out!
The Product Owner and the Team
The Product Owner's relationship to the development team allows both parties to maximize their productivity. Because planning activities occur at the beginning of the sprint, the team receives its negotiated sprint goals from the Product Owner and then has the entirety of the sprint to complete the work. And while the Product Owner must remain available to the team to answer questions, they are, ultimately, on their own to determine task-level management or the ‘how' in how will we get this work done (hence, self-organization). With the team storming to complete its goals, the Product Owner is then freed to perform other forward-looking activities, such as meeting with stakeholders, interviewing and surveying customers, release planning, backlog grooming and metrics analysis. In essence, the team's mandate to self-organize allows the Product Owner to step back from the granular perspective of each sprint's progress to consider big picture strategy, while still remaining "on-call" to answer the team's questions regarding ambiguity that may not have been cleared up during the sprint planning meeting.
Although backlog grooming-which is also referred to as backlog maintenance-is not a formal component of the framework, Scrum founder Ken Schwaber recommends teams dedicate five percent of every sprint to this activity (for example, a team using four-week sprints would spend one day grooming its backlog per sprint). During this meeting, the team, the Product Owner, and the ScrumMaster come together to prepare the backlog for the next sprint planning meeting. These activities typically include adding new stories and discussing new epics, or features, extracting stories from existing epics, and estimating PBI effort. In other words, backlog grooming represents an opportunity to streamline sprint planning meetings-thereby ensuring they do not stretch on for hours or days. When product backlog items contain clearly defined acceptance criteria and are estimated by the appropriate team members, the team can avoid planning meetings that are tense and overly long.
For a great way to estimate PBI effort, I would recommend Kane Mar's "spiciness" model, described here.
One thing to be wary of is ‘sprint raiding,' in which the Product Owner continues to assign work to the team mid-sprint. Although the Product Owner can answer questions and help the team better understand boundaries surrounding the acceptance criteria of PBIs, he or she cannot assign additional PBIs to the team during the sprint, unless the team has burned through all of its PBIs. If you find that this is happening on your team, I would suggest shortening the length of your sprints or encouraging the ScrumMaster to have a heart-to-heart conversation with the Product Owner as to how this can contribute to failure and chaos. (However, this scenario could also be indicative of weak acceptance criteria on your PBIs. ) If the Product Owner feels the need to