1

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?

  • 1
    You 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. – nvoigt Aug 23 '16 at 5:33
  • 1
    Please 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 Larimer Aug 23 '16 at 12:19
10

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 Development Team. The Product Owner is responsible for 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 Development Team works with the Product Owner to perform refinement. The Scrum documents suggest that this activity is about 10% of the capacity of the Development Team. That is, in a team of 5 working a standard 40 hour week, you can expect at most 20 hours of 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 come 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 Development Team 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 Development Team owns 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 members of the Development Team 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's methodical - the team starts at the top of the Product Backlog and fills the Sprint Backlog until they hit their capacity. They do this once at the start of the Sprint.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.