What is Scrum?

In non-agile process models, the customer says what he wants. Then, the product will be developed and delivered. Misunderstandings show up at the end when all the work is “done”. At this point, it is very hard to correct these misunderstandings to get a fully satisfied customer. A lot of projects failed by using non-agile process models. Here, agile process models like Scrum come into play.

The idea behind Scrum is that you deliver small product increments on a regular basis. These increments can be shown to the customer. Then, the customer can say whether he is satisfied with the progress and direction of the project or not. For example, it may be possible that you misunderstood what the customer wants. Such misunderstandings will show up early in the development process and can be clarified. In the end, it is more likely that you will have a very happy customer.

Following Scrum == being faster?

Scrum, or agile in general, does not mean that your team will work faster. Agile means, that you can attend to the wishes of your customer as soon as possible. For example, it could be possible that the priorities of your customer change and that one part of the software should be available earlier than what they thought initially. As I mentioned before, agile also means that you can detect misunderstandings very early because you hand the product increments to your customer on a regular basis. In case that there are misunderstandings, you can clarify the issues and correct what you may already have implemented. Therefore, such misunderstandings don’t preponderate that much.

Who is part of a Scrum Team?

Product Owner

The Product Owner talks to the customer to get to know what the customer wants. Based on these information, he clearly describes product backlog user stories and orders them by priority.

Scrum Master

The Scrum Master supports the time in living agile principles. He tries to clear obstacles which prevent the team from being productive and establishes an environment where the team can fully concentrate on its work. Additionally, the Scrum Master keeps an eye on what is going on in the team. He is also responsible for preparing and leading the retrospective.

Dev Team

The Development Team consists of people with different knowledge, e.g. programming, designing, testing, and domain knowledge. These people work on the user stories created by the Product Owner.

What is a Product Increment?

When working according to Scrum, you are working in sprints which have a duration of a few weeks, e.g. 1 week, 2 weeks, or 3 weeks. The goal of such a sprint is to get a product increment. A product increment is a new part of the software to be delivered, which adds new value to what you already have developed. It should be something you can show to your customer. Then, you can present it to your customer and talk about it to check whether this product increment is a step in the right direction.

What is a Sprint?

A sprint (afore mentioned as “regular basis”) is the time you are working on a product increment. In general, it is a very short period, e.g. 1 week, 2 weeks, or 3 weeks.

What is a Product Backlog?

In Scrum, you have two backlogs (lists of user stories). One of them is the so called product backlog which contains all user stories that need to be done for the whole project. It can become a huge list. The contained user stories should be re-prioritized continuously to always have the most important user stories on top of the list. This saves time when planning for the next sprint.

What is a Sprint Backlog?

The second backlog in Scrum is the sprint backlog. This backlog is much smaller and contains all the user stories that should be done in the corresponding sprint.

What is an Epic?

An epic is a large user story which cannot be delivered in one iteration. Therefore, epics are split into smaller user stories.

What is a User Story?

A user story is a functional increment. User stories are added to sprint backlogs. A user story contains a description of what needs to be done and acceptance criteria which define when the user story is done. Later on in the sprint planning, story points will be added to the user story.

What is a Sprint Planning?

A sprint planning is a meeting in which you plan the next sprint. In preparation, the Product Owner should have prioritized the user stories in the backlog. The user stories should have a description of what needs to be done and the acceptance criteria should be defined.

You can play Planning Poker, in case that you have such playing cards (you can search for them on the web). Often, Fibonacci numbers are used to define the sizes of the user stories. Additionally, there are cards which contain a cup of coffee which means that you need a break, or a question mark which means that you don’t have a clue about the possible size of the user story. The size of a user story can be

• What is the effort needed to get the user story done?
• How complex is the user story?

Now, the team grooms the user stories one by one. The first user story of the backlog is shown. Each team member chooses the card which represents what he thinks about the size of the user story. Obviously, the team should have defined what “size of a user story” means for them. Now, everybody shows his card and the team can discuss the opinions. The team members say what they think what needs to be done to explain how they came to their estimated user story size.

The first estimation does not have to be correct. It is possible, that team members

• forgot to consider things that need to be done for the user story or
• made a user story more complicated than it actually is

and decide to pick another card than the initially chosen one. It is possible to choose a lower or a higher estimation then because one might have overestimated or underestimated a user story. The team should decide for one size and write it down on that user story. If a team works together for a longer time, they know how much story points they can finish in a sprint. This number should not be exceeded because then it is more likely that the team will not be able to finish all the user stories of the sprint.

What is a Sprint Review?

A sprint review is a meeting which is performed after finishing a sprint. In this meeting, the team gives a live presentation of the results of the sprint to the product owner and interested stakeholders to get feedback, i.e. opinions, suggestions for improvement, praise, and criticism.

What is a Retrospective?

A retrospective is a meeting which is performed after finishing a sprint, too. The meeting is prepared and conducted by the Scrum Master. Goal of this meeting is to detect possibilities to improve as a team. Additionally, problems in the team can and should be a topic because solving them helps keeping team spirit and increases productivity.

What is a Burndown Chart?

A burndown chart shows the progress of a sprint, i.e. how many story points have been done and how many story points are remaining. With these charts you can predict how likely it is that you will finish all the user stories which have been planned for the sprint.

Below is an example of a good burndown Chart. All the user stories are closed continuously near the ideal burndown Line (grey).

The following is an example of a bad burndown chart because all the user stories are finished near the end of the sprint. Additionally, there are either a lot of user stories finished at the same time or there was a very large user story in this sprint. Large user stories should be avoided.

What is the Velocity?

The velocity is the number of story points your team is able to get done in one sprint. After some sprints your team will find out the number of story points it is able to complete by calculating the average of the completed user stories of the past sprints. Then, your team can use this number of story points as a cap for story points in further sprint plannings.

Recap: The Scrum Workflow

The following diagram shows how all the documents, meetings and results belong together.