Scrum Introduction

  • Because of their extreme uncertainties, it is not always possible to gather all the projects requirements upfront.
  • A project management method is needed flexible enough to deal with many change requests that appear during the project and keep the project team productive.
  • There are a number of systems designed to provide these two properties and one of them are called Agile Frameworks and include Scrum, Kanban, FDD and XP.

Agile Manifesto

In 2001, while on a skiing vacation, a group of software developers published a manifesto that has since been considered the heart of all Agile methods.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

  1. Individuals and interactions Over processes and tools
  2. Working software Over comprehensive documentation
  3. Customer collaboration Over contract negotiation
  4. 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.

Scrum vs Waterfall

Both Scrum vs and waterfall methodologies have their strengths, so it all depends on the type of project and its environment. Both approaches have effective planning followed by execution, monitoring and controlling.
In a nutshell:

  1. It is better to use Scrum if there are lots of unknowns, where the projects are more complex, difficult to define detailed requirements upfront and therefore to define estimates at the beginning of the project.
  2. It is better to use the traditional approaches when there are few unknowns, project is less complex, easy to define exact requirements upfront and therefore easy to estimate and plan the project from the very beginning.

Scrum Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

  1. Scope is not clearly defined and Product will gradually appear during the project
  2. Requirements change frequently and customer learns more about what they want as the project goes on
  3. Activities cannot be well defined upfront
  4. Estimating and planning is difficult
  5. Process is iterative with numerous cycles and each cycle depends on the previous one
  6. Success is mostly measured by customer satisfaction
  7. Incremental results have value and can be used by users

Waterfall Scope, Requirements, Activities, Estimation, Process, Measure of success and Results definition:

  1. Scope is clearly defined upfront with clear product description available upfront and similar projects were done before
  2. Requirements are well defined up front with few change requirements expected during the project
  3. Activities can be well defined upfront
  4. Estimating is possible and reliable
  5. Process is more long term and Project might be split into phases
  6. Success is mostly measured by achieving the project goals ( time, cost, scope…)
  7. Users cannot start using the products until the project is complete

Fictions about Scrum

Some of the most popular myths about Scrum include :

  1. Developers are free to do what they want. Fact: developers work in a productive and predefined framework and the Scrum Master makes sure they are following Scrum.
  2. Scrum gets rid of all paper work and allows the team to start developing right away. There are certain planning steps involved in every Scrum project and development can only start when the Sprint Backlog has been defined.
  3. All requirements in the form of stories must be agreed before the Development Team is allowed to start working on the product.  The Development Team can start working as soon as the initial stories of the Product Backlog are ready.
  4. Scrum is very easy to implement even without training. Fact: In order to run their projects well, everyone involved should have a good understanding of Scrum to be able to
  5. Scrum is just a set of simple rules. Fact: Scrum is a set of rules and a framework, plus a compatible work culture and ethic
  6. Scrum does not require you to have a Business Case. Fact: The Product Owner is responsible for ensuring that there is a feasible reason for performing the project and each of the stories should be aligned with that
  7. Scrum allows the Development Team to decide what will be delivered. Fact: A Team only decides on how to deliver; it is up to the Product Owner to determine what will be delivered
  8. Scrum Master is like a project manager. Fact: There is no one similar to a traditional project manager in a Scrum project as the Scrum Master makes sure the Scrum framework is followed
  9. The Product Owner is the project manager. Fact: The Product Owner only creates and maintains the Product Backlog, but does not manage the day to day activities of the Team
  10. The Product Owner is a representative from the customer. Fact: The Product Owner is one of the people from the performing organization and the contact point with the customer.
  11. Scrum tells us everything about managing projects. Fact: Scrum mostly deals with the definition and delivery of the products. Many of the business oriented aspects of the project are done outside Scrum.

Scrum Timeline

The first sprint can start when the business representatives have agreed to build something for the organization, providing a Vision Statement (idea, goal, vision) and a Product Roadmap (top level deliverables) that defines and describes the idea and the goal of the project. 
The Vision Statement and the Product Roadmap are not part of Scrum, but are essential parts of managing projects and are covered in other Agile frameworks.

Pre-Sprint Activities

What happens prior to the Sprints (Pre-Sprint):

  • The Vision Statement provides a concise description of the goals of the project which help the team stay focused on what is important from the organization point of view.
  • The Product Roadmap is an initial visual timeline of major product features to be delivered and is normally created by the Product Owner.
  • Stories are user requirements which will be turned into deliverable features, normally written by the Product Owner based on requirements from the customer.
  • All these stories make up the Product Backlog and the first Sprint can start as soon as there is enough stories defined, without the need for the Backlog to have 100% of the details.

Sprint Activities

What happens during the Sprints:

  • Sprint Planning meetings are held to plan what will go into a Sprint (a fixed period of time used to deliver parts of the final product). The Product Owner prioritizes these requirements and therefore decides on the contents of the Sprint Backlog.
  • These stories (features, functionalities or deliverables) make up the Sprint Backlog, so the Sprint Backlog is a list of all stories that will be developed in the next Sprint.
  • The Team breaks down (expands) these stories into tasks.
  • The Team then takes 2 to 4 weeks to deliver an agreed amount of stories.
  • The Team holds a Daily Scrum meeting (standup) of 15 minutes each day to collaborate with each other.

Post-Sprint Activities

What happens towards the end of the Sprint:

  • At the end of the Sprint, the Team demonstrates the completed stories (products) to the customer in a Sprint Demo (aka Sprint Review) meeting.
  • The last activity is the Scrum Retrospective meeting, where the team reviews the Sprint and looks for ways of improving it, integrating lessons learned (e.g. 3 items to change the following sprint).  The Scrum Master ensures that the Scrum process is followed entirely and offers coaching to everyone involved.