So from what I've understand by reading the tutorials on the Atlasian website, the backlog is populated by the project manager and can contain entries as abstract as he wants, with various degrees of importance. The backlog can (and should) constantly change to reflect the needs of the market and the feedback the product receives. At sprint planning, the team looks at the backlog, discusses the issues, tries to estimate them (either with story points, time or whatever the team likes). The team picks from the backlog what should be done in this sprint (taking into account that degree of importance set by the manager). Further changes to the backlog will not affect this sprint. Am I right? It seems like I'm missing something. Should the team go through everything in the backlog and try to give rough estimates? Or stop when it feels like it should stop? This part is unclear to me. How exactly is the team pulling work from the backlog into the sprint?
-
2You should really read a book about Scrum first. Learning Scrum by looking at the tool is like trying to learn how to drive by looking at your car's manual. It's helpful, but it does not teach you driving at all.– nvoigtCommented Aug 23, 2016 at 5:33
-
1Please do not just read any book; there a lot out there with bad information despite good intent. Go to the authoritative source, The Scrum Guide: scrumguides.org– Alan LarimerCommented Aug 23, 2016 at 12:19
1 Answer
the backlog is populated by the project manager
Scrum, as it's defined, doesn't have a role called "project manager". There are only three roles - Product Owner, Scrum Master, and Developer. The Product Owner handles maintaining the Product Backlog.
and can contain entries as abstract as he wants, with various degrees of importance
That's technically true. The Product Owner puts everything - features and functionality, enhancements, fixes, and other work items into the Product Backlog. However, to be actionable by the Development Team, there needs to be sufficient information in the backlog item. The order of the items in the Product Backlog indicates their importance - more important stories should be at the "top".
For the more abstract stories, the Developers work with the Product Owner to perform refinement. Refinement can be discussions, wireframing, prototyping, or other things to make the intent clear. The Development Team wants the items at the top of the backlog to be well understood before Sprint Planning.
The backlog can (and should) constantly change to reflect the needs of the market and the feedback the product receives.
Yes, the Product Owner can reorder the items in the Product Backlog. However, there may be technical dependencies on some of the stories. The Developers should have input regarding the order of work to ensure the quality of the product from a technical perspective.
At sprint planning, the team looks at the backlog, discusses the issues, tries to estimate them (either with story points, time, or whatever the team likes). The team picks from the backlog what should be done in this sprint (taking into account the degree of importance set by the manager).
Refinement should be an ongoing activity to understand forthcoming changes, since these may guide the design and implementation of the rest of the system. But as a general rule, the Sprint Planning meeting attempts to determine what work can be done in the upcoming Sprint and how to go about doing that work.
The team shouldn't just be picking randomly from the Product Backlog, but it should generally go top-down. There may be some exceptions - some items that aren't well understood or technical dependencies on lower priority stories are two examples.
The amount of work picked from the Product Backlog and placed into the Sprint Backlog is based on the team. If the same team has been executing on the project using Scrum for a while, previous Sprint performances are a good baseline. It's tricky to get it right in the initial Sprints for a new project or a team that has new people on it.
Further changes to the backlog will not affect this sprint.
The Developers own the Sprint Backlog. There is always room to collaborate with the Product Owner to change the Sprint. For example, if a higher priority bug fix is required, a lower priority bug or a new feature may be swapped out. However, since Scrum (and the agile methods) are about sustainable performance, you wouldn't want to add work randomly - you want to make sure that things that are added also have items removed.
The Product Owner maintains the Product Backlog in isolation from the Sprint Backlog, and changes there won't affect the current Sprint.
Should the team go through everything in the backlog and try to give rough estimates? Or stop when it feels like it should stop?
The Developers participating in the refinement activities (which should be most, if not all, of the team) should be able to get rough estimates of the effort needed to do the work. Once the Backlog Items are sufficiently understood, though, the team only needs to determine that their Sprint is loaded to an appropriate capacity. They don't need to estimate every item. They can also refine estimates as they learn more about the problem space.
How exactly is the team pulling work from the backlog into the sprint?
It varies by team. As part of the Sprint Planning, the Product Owner and Developers should collaborate to create a Sprint Goal. Then, Product Backlog Items that support this Sprint Goal are selected. If the team believes that they have additional capacity, they may add additional Product Backlog Items that are unrelated to the Sprint Goal to their Sprint Backlog so it becomes obvious what work is appropriate to do during the Sprint.
