Scrum Trainning


Why Agile? Well...

At a certain point all of us may agree with this image.

Image with a joke about how software development industry used to miss understand user needs.


What we will be having fun with during the next hours.

  • Differences!

    Agile vs Classic Product Development

  • Culture!

    Agile Values and Basic Principles

  • Who?

    Scrum Roles and Process

  • How!

    Basics of Agile Product Development




Classic Product

Classic product development

Diagram illustrating how watterfall process works.

What about teamwork?

Watterfall can be compared to a relay race

Seems to me that this approach does not promote a complete team environment.

Image of a realy race.

What about considering a cooperative approach?

Image shows a team working all together.


Core idea of agile software development is a continuous (incremental) development of the product while continuously considering customer feedback.

Image shows an iterative proccess development with user in the center.


Agile Values


Basic Principles

Manifesto Values

Individuals and interactions over processes and tools.

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

"That is, while there is value in the items on the right, we value the items on the left more."

Agile Principles I

1. Highest priority is to satisfy the customer with early and continuous deilvery of valuable software.

2. Welcome changes even in late development.

3. Deliver working software frequently, from a couple of weeks to a couple of months.

4. Business people and developers must work together daily throughout the project.

Agile Principles II

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development and keep a constant pace indefinitely.

Agile Principles III

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


Scrum roles


Development process

Scrum Terminology

Scrum is a Rugby formation - players stand closely in touch with each other.

  1. Focus on Team
  2. Joint discussion of the next move
  3. Self organization

Scrum is a Proccess-Framework.

  1. Lightweight
  2. Easy to understand
  3. Hard to master

Scrum Components

Image shows what Scrum is made of, roles, definition of done and ceremonies and artifacts.
Image describing the entire scrum proccess.

Product Owner (PO)

The PO is owner of the product and steers the development of the product from the functional point of view. He maximizes the product value by maximizing the outcome of the development team work.


  1. Bundle knowledge about the product and its environment.
  2. Maintain the product backlog by creating and sorting product backlog items (PBIs).
  3. Provides the developers enough information about the product and the PBIs, so they can implement them.
Ilustration about where does the PO stand in the process development.

PO and the Value Curve

In simple terms, PO is the person in charge to determine what brings more value to the product faster.

The image shows that twenty percent of the features brings eighty percent of value to the product.


The Developers steer the development of the product from a technical point of view. Main goal is to transfer PBIs into increments.


  1. Size: 3-9 (why?)
  2. Self organizing
  3. Cross-Functional
  4. No hierarchies, no sub roles

The image shows taks performed by the development team, transform PBIs into to increments.

Scrum Master

The Scrum Master is responsible that Scrum is understood and enacted. He is consultant for Scrum itself. For doing so, monitors the way the team works and supports it if desired.

The more unexpererienced the team is, the more important is to have a Scrum master. For experienced teams and companies the scrum master might be omitted.


  1. Ask the team!
  2. Make himself unemployed.
  3. Coomunication of Scrum Values in his company.


Kind of a Micro-Project, a container for all event and the heart of Scrum.

The image represents a sprint with 2 to 4 weeks duration, with all the cerimonies inside it. Starting with Sprint Planning and ending with sprint review and retrospective.

If the team decides for a short duration there will be space for more inspections and adaption, however in side effect there will be less space for development.

At the other hand with longer Sprints where will be less inspection but more time available for development.

Important Reminder!

An Sprint must only be cancelled in a really exceptional case, and only by the PO!

Sprint Planning

Planning is the cerimony where the PO and Devs decide what can be done during the Sprint. Eight hours or less is the recommended duration for sprint with four weeks.


  • Product Backlog
  • Increment from that last Sprint
  • Developer team capacity


  • Written Sprint Goal
  • Sprint Baclog


The method commonly used to estimate PBIs is called Planning Poker.

The unit used to measure the size of a PBI is called Story Point, it does not represent time, the value just tells us how big the PBIs is. For example instead of a number it is possible to use T-Shirt sizes to measure, XS, S, M, L, XL and so on.

When estimating an PBIs each member of the dev team analyses separately the PBI and chooses one card from the possible ones. The smaller the number the easy is to have that PBI completed, for example a PBI with a 3 story points is way smaller than a PBI with a 40 story points.

An image that shows a commonly used pattern for story points.

Daily meeting

An everyday exchange between all developers about the current activities of each team member. The duration is equals or equals fifteen minutes for a team with nine team members. It must happen at the same place and same time.

These questions should be answered by each team member

  • What I have done since yesterday (since the last daily)?
  • What I will do today ( until the next daily)?
  • Are there blockers / impediments?

Bigger topics should be moved to an offline discussion in order to keep the timebox.

Sprint Review

The whole Scrum-Team takes part on the Sprint-Review, organized by the PO or Scrum Master, including the stakeholders (users, partners, leadership, members, etc.)


  • Demonstrate the results of the recent sprint (inspection).
  • Agree on next steps to increase the product value(adaptation).

The image shows the sprint review, where PO, developers presents what was achieved during the Sprint to the stakeholders.


Closed meeting for developers at the end of each sprint with an duration of three hours for a four weeks Sprint.


  • Investigate the recent sprint.
  • Identify potential improvements.
  • Create concrete plans for improvements to realized during the next sprint.

The image shows the sprint review, where PO, developers presents what was achieved during the Sprint to the stakeholders.

Dev Slack

A non official Scrum cerimony, that aims to keep the team involved to search for new ways of doing things. Usually happens between the Retrospective and the Sprint Planning

During the slack develoepers can work on any tech stack that they want, study or do whatever they want that can contribute to the development of team skills. This was created to keep a maintainable environment.

The absence of pressure during this time sets free the creativity and cool stuff may arise. Usually after a couple of slacks a developer present to the others what he is working on.

Team Velocity

After the execution of a couple of Sprints it is possible determine the velocity of the team.

It isn't as precise as you may want however looking for Sprints that were completed it is a good way to predict how much work can be done.


Containers for results produced by the Scrum Team.

Image shows team members transforming knowledge about the product in to product backlog, sprint backlog and increment.

Product Backlog

A simple list of everything which can be introduced in the product during the following Sprints, ordered by priority. Only the PO can add or remove items or change priorities.

Image shows team members transforming knowledge about the product in to product backlog, sprint backlog and increment.

Backlog in Jira

Image shows a backlog made with Jira

Product Backlog Item (PBI)

Each PBI must have a description, priority, estimation (estimated by the dev team during the planning).

The PO refine and enriches PBI iteratively changing them as more is learned (product, market, technologies).

A meeting for refinement on PBIs can be done with help of stakeholders and developers, this is usually called Backlog Grooming and it is not part of official Scrum.

Level of details for PBIs

The level of detail must be reduced for PBIs that are going to be implemented later. The less the value of a PBI(from the current point in time), the less the level of detail.

Image shows team members transforming knowledge about the product in to product backlog, sprint backlog and increment.

Definition of Done (DoD)

The DoD serves as a checklist. It can be only set to done when all criteria of the DoD are satisfied.

Its a list created by the developers and communicated to the PO. It can be continuously improved during the sprints.


  • Strenghtens trust relationship between PO and Developers.
  • Facilitates a common understanding of the Developers when a task is done.

Sprint Backlog

A list containning all the PBIs that will be developed in the current Sprint.

It belongs to the developers and serve as a central point of what needs to be done and a transparent indicator to the whole Scrum-Team.


The increment is what is usually known as the Product.

Potentially shippable after each sprint.

Inspiration of Scrum Creator


When working in projects that has a 'defined' scope, group the team and identify all the user stories at the beginning.

After defining what is possible to be done in the future, estimate them. This will be difficult but necessary, since stakeholders will be asking for progress. These estimations will change in future but a starting point is necessary.

Developers tend to avoid this premature estimation because they thought that this will be used against them in future, however this is not the point in Scrum at all.


Basics of Agile

Product Development

Automation and standardization

Image shows what happens when the developer send the code to the repository.


Agile simply does not work without testing. They must be implemented and automatized by the developer

Image shows what happens when the developer send the code to the repository.

Who never did that, huh?

Live Demo

Show tools and current status of projects.

Thanks for your attention.