Frequently asked questions in Scrum

I’ve been training and coaching Scrum teams for many years and in that time I’ve seen the same questions pop up over and over again. With Jim Bowes taking a well-deserved vacation I thought I’d jump into the Agile blogging fray to provide my answers to some of the most commonly asked questions in Scrum.

Who owns the sprint backlog?

It’s not surprising that confusion arises here since the Product Owner is responsible for the Product Backlog and it’s natural to assume that they’re also responsible for the Sprint Backlog. However, the Scrum Guide is quite clear that “only the Development Team can assess what it can accomplish over the upcoming Sprint.” So it’s not on for the Product Owner to unilaterally change the Sprint Backlog after the sprint has begun.

The Sprint Backlog will certainly change during the course of the sprint as new information comes to light but those changes should always be the result of a conversation between the Product Owner and the rest of the team. And the changes shouldn’t jeopardise the Sprint Goal, which the team authored together. In short, the whole team owns the Sprint Backlog.

How many story points should a team tackle per sprint?

There’s no real answer to this one since every team is different. Aside from which, it’s important to remember that story points only estimate the size of stories relative to each other, not absolutely. And that story points are not intrinsic to Scrum, merely a tool that many teams/organisations find useful.

One of the main benefits of Agile is to deliver the most valuable features first. If those features are represented by stories which are too large to fit comfortably in a single sprint they can almost certainly be split into smaller stories.

Ultimately it’s up to the team to decide together how much work they can take on in the coming sprint.

Why can’t the Product Owner also be the ScrumMaster?

To me this seems like a crazy question, equivalent to “why can’t the bus driver also be the bus conductor?” And yet I often see this conflation of roles.

The role of Product Owner and ScrumMaster are very much mutually exclusive. In fact, there should be a natural tension between them: the Product Owner representing the interests of the business within the team; and the ScrumMaster representing the interests of the team within the business. When one person plays both roles they’ll naturally gravitate to one or the other depending on their background/affiliations/disposition – which isn’t fair to either the team or the business.

When should tasks be assigned?

In theory Scrum teams are cross-functional and self-organising and, as noted above, the whole team is responsible for the Sprint Backlog (and achieving the Sprint Goal). As long as the team can agree on how the work gets done in the Sprint Planning meeting then it’s not strictly necessary to apportion every task to a team member.

But many teams – especially those where each member specialises in a different discipline – find it useful to work this way, apportioning tasks after the Sprint Backlog has been agreed upon. These mini-plans shouldn’t be set in stone though – they should be able to change and adapt as the sprint progresses.

When does estimation happen?

Stories need to be estimated before they can make it into a Sprint Backlog so it’s helpful if a good number of stories are estimated prior to the Sprint Planning Meeting. This usually takes place in a separate Product Backlog Grooming (or Management) Meeting – where the whole team together estimate the relative sizes of the stories at the top of the Product Backlog.

While backlog grooming can be incorporated into Sprint Planning there is a distinct advantage to having separate meetings. It keeps Sprint Planning focused on the twin outcomes of deciding what work will be done in the coming sprint and how it will be done.

Who defines the definition of ready/done?

These definitions are tremendously helpful for regulating the quality of the work output by the Scrum team. An inadequate Definition of Ready leads to confusion in the team about what’s required and an inadequate Definition of Done leads to rework as features are released too early.

It’s up to the team as a whole to agree on both definitions rather than be handed ready-made versions. Both definitions will evolve with the team as its experience and aptitude increases. They should be revisited frequently – the Sprint Retrospective is the perfect opportunity.

In organisations with multiple Scrum Teams with shared definitions of Ready and Done, the definitions should be agreed at Scrum of Scrum meetings, with representatives from each team present.

How big should a scrum team be?

There’s no single answer to this one. In 2003 Jeff Sutherland said that a Scrum team should consist of no more than seven members. Now the Scrum Guide recommends a team size of between three and nine members. In general, the larger the team, the more work it can take on. But greater complexity is also introduced in planning and coordinating the work of larger teams.

What is velocity?

Velocity is a metric used by organisations to track how much work a Scrum team is getting through per sprint. It’s usually measured in story points. While it can be a useful indicator of productivity it shouldn’t be relied upon too much.

As in the old joke about the drunk looking for his car keys under a streetlamp far away from where he dropped them (because that’s where the light is) a reliance on velocity is seductive because we can’t directly measure how much value a team is releasing. But velocity is not a proxy for value.

How should the product backlog be ordered?

The Product Backlog should be ordered in such a way that the highest value, most detailed stories are at the top and the lowest value, least detailed stories at the bottom. The Product Owner is responsible for ordering the Product Backlog in such a way that maximum value is created for the business.

A common misconception is that the backlog should be ordered by priority. But when we consider that the Product Backlog is continually changing and evolving with the product – based on feedback from stakeholders etc – then it’s easy to see how a high-priority item might make it into the backlog but not yet be sufficiently detailed to take a position near the top.

Who runs the sprint demo?

The Sprint Demonstration Meeting is a chance for the team to gain feedback on the latest product increment from stakeholders. It’s facilitated by the ScrumMaster and should be attended by the whole team. In order to engender as conversational an atmosphere as possible it shouldn’t be treated with too much formalism, so to ask who runs it is probably the wrong question. A better one might be “what further information can we gain about how to make the product more valuable from the Sprint Demo?”

What is an Epic?

An Epic is just an item in the Product Backlog that hasn’t been broken down into stories small enough to be worked on yet. Once those stories have been written it might still be useful to group them together under an Epic as it helps to think about the larger feature or theme to which those stories contribute e.g. a shopping cart or a sign-up process.