title	subtitle	author	date	subject	keywords	lang	titlepage	logo	titlepage-rule-color	page-background	theme	separator	verticalSeparator	notesSeparator	revealOptions
Scrum Introduction	Short recap about scrum for Fontys Venlo	Stefan Sobek	2021-03-31	Short recap about scrum for Fontys Venlo	Fontys Markdown Agile	en	true	images/fontyslogo.png	400070	images/fontyslogo-background.png	night	<!-- s -->	<!-- v -->	<!-- n -->	transition transition-speed slideNumber history progress width height parallaxBackgroundImage parallaxBackgroundSize concave fast true true true 1248 800 images/fontys-parallax-all-dark.jpg 2100px 1024px

Scrum Introduction

An introduction to Scrum for usage in Fontys venlo Software Engineering and Business Informatics study

Scrum taken serious

Funny example for usage of scrum: Scrum Master - Funny movie about The Power of Scrum

Topics

• What is Agile?
• What is Scrum?
• Why Scrum?
• Scrum Framework
• Teamwork: Roles in Scrum
• Meetings in Scrum
• User Stories
• Performance

What is AGILE?

• Time focused
• Iterative
• Incremental product development
• Deliver small pieces
• Feedback

What does it mean if somebody says, he works agile or uses an agile process? Time focused, usually using Time Boxing: Do not exceed time given for meetings. Iterative, doing the work in iterations, for instance, doing analysis, design, implementation and testing again and again. Incremental product development means creating small pieces of functionality and thus Developing these small pieces The most important thing in agile is the feedback part.

Agile Manifesto

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

So what all these agile processes have in common is that they follow the 12 principles of the agile manifesto. This manifesto was developed by some guys, e.g. Robert C. Martin (Uncle Bob), Ron Jeffries (Creator of Spring), Alistair Cockburn (Use Case Expert), Martin Fowler, Kent Beck, Ken Schwaber, Jeff Sutherland… asf.

Individuals and interactions over processes and tools

Individuals are more important than processes and tools. The people are doing the work.

Working software over comprehensive documentation

This does not mean that documentation work should be skipped. It means that only the documentation which is necessary must and should be created. E.g. if

Customer collaboration over contract negotiation

Have the customer on-board. The customer should work with the team together instead of insisting on contractual parts which can and mainly will change.

Responding to change over following a plan

Be able to handle changes - better - embrace changes. Projects will change thus managing changes well means managing the project well.

12 Principles

The 12 principles are based on the Agile Manifesto.

• 1 - Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

• 2 - Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• 3 - Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

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

• 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. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

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

What is Scrum?

• Agile Managementframework
  • Ken Schwaber
  • Jeff Sutherland
• Empirical process
• Goal is to produce
• Does NOT ensure success
• Is hard work

➡ www.scrumguides.org

The Scrum Guide

• Self organized teams
• Transparency
• Continuous improvement (Inspect and Adapt)
• Priorities set by business
• Iterative steps (Sprints)
• Requirements in backlog
• No specific development method recommended
• Few but strict rules

Agile/Scrum is NOT:

• “Just start to work”
• Everybody can do what she/he wants
• There are no rules
• Nobody needs processes
• Only programming - no planning - docs

Scrum project profile

There are different project types:

Innovation

• Derivative, a derivate of a succesfull product
• Platform: a new version of an existing product with much market research needed etc.
• Breakthrough product: extremly challending, no real market yet exists. Customers need to experience your product.

Technology Level (technically difficult)

• Low-Tech: no rechnology risk as good known tech level
• Mid-Tech
• High-Tech: probably unclear requirements for a long time etc.

Complexity

• Assembly: Building straight-forward product
• System: Building ships, cars building or complex software programs.
• Array: multiple systems, many stakeholders, high risk.

Time pressure

• Regular: Normal time pressure level - if that can be said in a project.
• Fast/Competitive: You need to be fast with your project to be competitive
• Time-Critical: Absolutely time crititcal, e.g. rules need to be implemented or a high penalty must be paid.
• Blitz

The Scrum roles

• Planning: 1w / 2h, 2w / 4h… max 8h
• Review: 1h for 1 week sprint  1w / 1h, 2w, 2h… max 4h
• Retrospective: 45m for 1 week sprint  1w / 45m, 2w / 1,5h... Max 3h

Product Owner

• Product Backlog
• Business Value
• Contact person for team

• The product owner is responsible for the product backlog - means makes sure it is up to date, that the product backlog items (usually User Stories) are estimated on time and that they are prioritized. Can and should ask for help of the team!
• He is the responsible person for the business value. Thus he is in charge - he answers questions regarding what feature to do next. He either can decide on his own or gets the answer from somewhere else.
• Thus he is the contact person for the team regarding all questions. Of course he can delegate, but he is responsible!

Development Team

• 3-9 people
• Estimations
• Delivers releasable increments
• Interdisciplinary
• Self organizing

Usually a team consists of 3-9 people. Why? Well, more people, more communication effort. The team does the estimations and is doing the work thus after every sprint/iteration deliver an increment. The team should be able to do the whole work, meaning having an interdisciplilary team will empower the team to do all the work on its own. Nodoby tells the team exactly what and how to do the work. But, the product owner defines what should be done first - priorisation.

Scrum Master

• Ensures process
• Helps removing impediments
• Moderation
• Coaching

The Scrum Master is a coach of the team. With this role he not only ensures that the scrum process will be followed, but he will coach the team how to follow the process. This could mean general coaching on work, but maybe also lecturing for providing agile and scrum knowledge. He will help removing impediments. This does not mean he will remove them in person, but supporting and finding solution for solving them. Usually a Scrum Master is not only a coach but normally experienced person in project environments.

Product Backlog

• list of everything ➡ for the product (Backlog Items)
• single source of requirements
• Product Owner is responsible
• Product Owner manages Product Backlog
• Product Owner puts new Backlog Items into Product Backlog
• Order of Backlog Items in Product Backlog defines importance

• Product Backlog is a list of everything which might be needed for the product (Backlog Items)
• Product Owner is responsible for maximizing the value of the product and the work of the Development team.
• Product Owner responsible for managing Product Backlog
• Product Backlog is the single source of requirements
• PO puts new Backlog Items into PB
• Order of PB in PO defines “importance” and thus steers which one to do next
• Product Backlog Items can be very coarses grained like:

User Administration or Secure Server Connection

or they can be very precise:

As an administrator I want to have a user account blocked on fraud detection, so that this user is not able to use the services anymore. Testcase: When a new user is created AND the user triggers a fraud scenario THEN this user must be blocked in the backend and is not able to login again.

Product backlog items as User Stories

Short and simple description of features from the perspective of the user

As an Administrator, I want to check and confirm a new blog entry so that it is visible on my webpage.

Or

An Administrator can check and confirm a new blog entry.

User Stories should follow INVEST acronym

• Independent
• Negotiable
• Valuable
• Estimatable
• Small
• Testable

User Stories should contain Acceptance Criterias

Product Backlog example

Scrum Meetings

Sprint Planning Meeting

Participants

• Scrum Master
• Product Owner
• Develoment Team
• Timeboxed: Length roughly 2h per 1week sprint

• Scrum Master teaches how to stay in timebox
• Goals:
  • Which work to complete in the next sprint
  • and how?
• Team decides based on capacity and velocity how much work can be done until end of next sprint
• Outcome: Sprint Goal and Sprint Backlog

Estimations

• done in Planning Meeting
• Estimate relatively e.g.
  • Story Points
  • T-Shirt Sizes
• How? Playing Planning Poker
• Fibonacci

Backlog example

Sprint Backlog example

Sprint and Daily Meetings

• Team doing the work in the Sprint

Daily Meeting

• Daily is NO Management reporting meeting!!!
• Daily Meetings (15 min Timebox)
  • What did I do/finish yesterday
  • What will I do/finish today
  • Issues? (Impediments)
• No detailed discussions in daily
• Getting the team informed about the progress
• Team usually discusses after the meeting

Sprint Review Meeting

• Time boxed meeting (1h per 1 week)
• Participants usually Development Team, Product Owner, Scrum Master and key stakeholder
• Team demonstrates the results (Done User Stories)
• Product Owner accepts or not accepts User Stories
• Probably new Product Backlog Items occur

Sprint Review Meeting examples

Another Sprint Review Example

And another Sprint Review

Definition of Done

• What means a User Story thus a feature is done?
• First of all a User Story is functionally done if the Product Owner is “happy” ➡ Acceptance Criteria
• What about the quality?

Scrum does not allow negotiation according to quality.

Setup a Definition of Done - Example

• Code must be Unit tested. Tests GREEN ✅
• Code must be checked in into Version Control System ✅
• Successful Automated build, all tests GREEN ✅
• Code and/or Spec-Review successfully done (or Pair programming) ✅
• Code Coverage >= 85% ✅ 💯
• Installation manual created/updated (if applicable) ✅
• Administration manual created/updated (if applicable) ✅ 📔
• Acceptance test done (Demo for Product Owner) without errors ✅ 🙍
• Demo done on Integration Environment (not on DEV-machine) ✅ 💻
• ...

Sprint Retrospective

• Most important Meeting
• What went wrong / what went well regarding process / work / people / tools
• Inspect and Adapt
• Plan improvements (actions)
• Scrum Master moderates

Retro example

Another retro example

Again a retro example

Burndown Chart

• The burndownchart allows to track the performance. There is an optimal Burndown-line (gray) drawn which gives a hint how you are performing. Usually a team does not follow the optimal line, but the trend should do.

How to estimate?

• How much can we do in the next sprint?
• Check what was done in the last sprints
• Velocity is Storypoints DONE in the last sprint(s)
• Average Velocity: 25 SP

Velocity - Estimated vs Real

• The team captured the total capacity - how many people are available, and also put the estimated value and the real velocity value. This gives a very nice performance view.

Howto start?

See Howto Start

Additional information

Books

• Agile Product Management with Scrum (Pichler
• Scrum - Agiles Projektmanagement erfolgreich einsetzen (Pichler)
• Agile Coaching (Davis /Sedley)
• Agile Retrospectives: Making Good Teams Great (Derby / Larson)