About Scrum

1. What is Scrum?

Scrum is a framework that helps teams work together. Much like a rugby team (where it gets its name) training for the big game, Scrum encourages teams to learn through experiences, self-organize while working on a problem, and reflect on their wins and losses to continuously improve.

While Scrum is most frequently used by software development teams, its principles and lessons can be applied to all kinds of teamwork. This is one of the reasons Scrum is so popular. Often thought of as an agile project management framework, Scrum describes a set of meetings, tools, and roles that work in concert to help teams’ structure and manage their work.

2. What is the difference between Agile and Scrum?

The Agile manifesto was introduced as an answer to problems with the Waterfall model and its approach in 2001. Since the introduction many types of Agile methods surfaced, based on the Agile principles. Right now, Scrum is the most popular of them due to its simplicity. Other types are: Kanban, Extreme Programming, RUP, DSDM and Lean Development.

3. Why should I use Scrum?

You should use Scrum not because you think you have to, or because everybody else is doing it. Only do it if there is a real problem that you want to solve. To name a few examples:

If you have problems with delivering software at the right time.
If your projects spent too much money for too little value.
If you think you can’t keep up with market trends.

Just remember that Scrum will not solve all of your problems, and when implemented badly it might very well make things worse.

4. Can Scrum work in a large organization?

Of course! Large organizations tend to think they are special, that general rules don’t apply to them. Other arguments you might hear from these organizations are:

Quality Control is too important for us to do Scrum,
Our projects are too complex to do small increments in Scrum,
Senior Management does not endorse Scrum.

The best way to overcome this resistance is often to start small, and prove that it does work. So, is it not easy to implement Scrum in a large organization, but it is not impossible either.

5. What is a user story?

A user story can be seen as a requirement. It clearly describes what is needed for who and why. It is often written in the format: As a role I want something so that I can do some kind of benefit. User Stories can vary in granularity. If defined generally it is usually called an Epic. When User Stories are prioritized the team should refine them, so you end up with User Stories that can be implemented in one sprint. When selected for a sprint the Team defines Tasks to implement the User Story.

6. What is the velocity of a team?

The Velocity of a team is the amount of Story Points the team can implement in one sprint. Unlike Function Points, Story Points are not comparable between teams. Every team builds up its own measurement system for Story Points. Every team is challenged to improve their Velocity. The Retrospective is one of the instruments to achieve this.

7. Can I still use function points for measuring?

Surely you can! But it’s not part of Scrum. Function Point Analysis is a method to measure software. To do this it breaks down the system into smaller components. FPA measures systems from a functional perspective, independent from the way they are implemented. The only variable is the amount of effort needed to implement the function points. So, it can for example be used as a tool to compare the effect of different development tools. It is also used as a way to calculate project budget and throughput time of a project. Function Points can be used to compare between teams, which is not possible with Story Points. Note that FPA can only be done by experts. FPA offers features that Scrum does not have, so it can be beneficial to use it.

8. Why does Scrum use Story Points instead of hours?

Excellent question!

Story points are a relative way to measure the effort it takes to realize a User Story. So why not use hours?

This is because every team member has different skills, which means the time it will take to realize a user story will differ per person. Rather than taking some kind of average value that does not mean much, you want to measure the complexity of the User Story. It is much easier for team members to agree on the complexity of a Story than it is to agree on the number of hours. This is also the reason why you should not try to translate Story Points to hours. Quite often you see rules of thumb where one Story Point equals 4 or 8 hours. Try not to do that!

User Stories are the responsibility of the Product Owner. The PO decides on the priority of the User Stories on the Backlog Items. For the PO Story points are a better unit of measurement than hours, because he does not need to know how the stories are implemented. Every User Story is implemented by executing a number of tasks. Tasks define how the User Story is implemented and are the responsibility of the Team. Tasks are usually measured in hours and not in Story Points.

9. 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/organizations 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.

10. 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 he’s 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 jeopardize the Sprint Goal, which the team authored together. In short, the whole team owns the Sprint Backlog.

11. Why can’t the Product Owner also be the Scrum Master?

This seems like a crazy question equivalent to “Why can’t the bus driver also be the bus conductor?” And yet this conflict of roles is often noticed.

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.

12. When should tasks be assigned?

In theory Scrum teams are cross-functional and self-organizing 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 specializes 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.

13. 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 estimates 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.

14. Who defines the definition of ready/done?

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 organizations 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.

15. How big should a scrum team be?

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.

16. 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.

17. What problems can I expect when implementing Scrum?

A lot! As culture means behavior of people, most of the times culture has to change. There will be opposition. People will mock it. Conservative parties will demand proof. They will want to see solid business cases before any approval is given. In the beginning it is often swimming against the current. You have to be determined. Don’t give up easily.