Project management 4. Scrum

Contents

What is Scrum?

  • Scrum is a framework for delivering products (usually software)
  • Designed for teams of ten or fewer members
  • Scrum Values
    • Minimal chance of failure: product is worked on in small increments
    • Transparency: changes are visible to the team
  • Work is split to Sprints: goals that can be completed within time-constrained iterations
    • Sprints are most commonly two weeks long (for us, shorter)
    • Progress is tracked and re-planned in Dailies, 15-minute time-boxed meetings

Why Scrum?

  • Through its practices and principles, Scrum creates conditions to achieve good results
  • Scrum gives agency to team members: meeting the goal is a team effort
  • Scrum creates transparency: problems get addressed early
  • Scrum isn't magic: you need to continuously enforce its practices in action
  • Scrum facilitates communication, but doesn't solve any problems for you — you have to actively enforce its usage!

Scrum roles

Scrum Team consists of three roles: Product Owner, Scrum Master and the Dev team.

Dev team

  • Small team that aims to deliver a product
  • Organizes itself and its work
  • Collaborates with Product owner
  • Creates product increments in a series of sprints

Scrum Master

  • Helps to facilitate usage of Scrum for the team
  • Ensures the Scrum framework is followed
  • Aims to improve team's workflow
    • Basically an acting producer!
  • Can be a part of the dev team (a "peer leader")
    • ...but should not be the Product Owner
  • Can be a different person every Sprint
  • Scrum.org gives courses where you can get a Professional Scrum Master™ certification ($200)

Product Owner

  • Accountable for profit & loss
  • Listens to the customer's wishes
  • Manages the Product Backlog
  • Representation of stakeholders and customers to the Dev Team
  • Chooses what to release — and when

Other Scrum-adjacent roles

  • These aren't part of the Scrum team, but can be important personnel in the product lifecycle:
    • Stakeholders
      • People outside the Scrum team who have an interest in the product
      • Sales, marketing, end customers, etc
    • Customers
      • Communicates their needs and wishes to the Product Owner
      • Is often more interested in the end result than technicalities

Project timeline

Starting a new project

  • When a new project is started, a Product backlog is created based on the customer's needs and the available time
  • The project timeline is split into Sprints, around which the whole Scrum process revolves around
    • Sprints are usually from one week to a few weeks long
    • New Sprint menas new tasks to the Dev Team.

Product backlog

  • Holds the requirements for the product
  • Managed by the Product Owner
  • Composed of tasks
    • Unit of deliverable work
    • Well-defined completeness
    • Ideally completable during a single Sprint
    • Features, Bugfixes, etc...

Sprint backlog

  • A list of tasks to be completed during the Sprint
  • Selected from the Product backlog
  • A forecast of what is aimed to be done during the Sprint, not a promise!!
  • Often visualized as a Kanban board in Trello, GitHub, GitLab, etc.
    • In GitLab, Sprint backlogs can be created in the Milestones tab
width:

Definition of Done (DoD)

  • When is a task considered done?
  • This is decided by the Dev team in a Sprint Retrospective (more about it soon)
  • DoD can change as project progresses
    • "It works" -> "It passes tests"

Events

Sprint events

  • In Scrum, Sprints are paced by events, also known as Scrum "ceremonies"
    • First day: Sprint Planning
    • Every day: Daily Scrum
    • Last day: Sprint Review & Sprint Retrospective

Sprint Planning

  • Sprint Planning starts a new Sprint
  • The whole Scrum team attends
    • The whole Product Backlog is inspected
  • A Sprint Goal is created and dissected into a new Sprint Backlog
    • The Sprint Goal is immutable
    • The exact implementations are not discussed
      • Those are rather left for the Dev Team to decide!
  • New tasks are given to the Dev Team

Daily Scrum ("Daily")

  • Only the Dev Team attends the Daily, with these goals in mind:
    • Inspect the progression towards the Sprint Goal
    • Inspect how the Sprint Backlog is clearing out
    • Create a plan for the next 24 hours
  • Max. 15 min long!
  • Keeps everyone on the same page
    • Optimizes collaboration and performance of the Dev Team
  • Sometimes held as a stand-up meeting: Nobody sits down to enforce the sense of urgency and minimize time-wasting chit-chat
  • Example topics to address in a Daily:
    • What have you achieved since the last Daily?
    • What problems have you faced?
    • How does the team address problems?
    • Is there need for (re)allocation of tasks?

Sprint Review

  • The Sprint Review is attended by the Scrum team and stakeholders
  • Goal: Offer feedback and open up discussions about the Sprint
  • Starts off with a feature demonstration
  • Product Owner presents the state of the Product Backlog
    • What is releasable?
  • Dev Team tells what happened during the Sprint
    • How different problems were addressed?
    • What was their effect?
  • Everybody provides and listens for feedback

Sprint retrospective ("Retro")

  • A Retro is held after every Sprint Review
  • Only the Scrum Team attends
    • Worries and thoughts are brought up
  • Possible discussion topics
    • What went right?
    • What should be improved?
    • Tools needed and used?
    • The suitability of the Scrum process?
    • What does Done mean, and should it be redefined?

Scrum Master tasks

Continuous tasks

  1. Make sure the task board on GitHub is up to date.
  2. Make sure everyone is able to attend the dailies.
  3. Make sure everyone is heard and contributes at dailies.
  4. If someone needs help, you help them find assistance or assist them yourself.

Before the dev meeting

  1. Make sure the task board on GitLab is up to date.
  2. Make sure someone is ready to present the newest working version of the program, with all the new changes pushed
  3. Write down the state of tasks listed in the Sprint backlog
  4. Discuss what problems were encountered during the last Sprint, and how were they addressed.

--- * ***Cross-discipline teams***: Enables teams to deliver features and mechanics that have clear value * ***Self-management***: Enables teams to select the amount of work they can commit to every sprint and complete that work through whatever means they find appropriate * ***Self-organization***: Enables teams to have a degree of authority and responsibility to select their membership * ***True leadership***: Provides leadership focused on mentoring and facilitation to free the best performance possible from the team

## Cross-discipline teams * Team members share the same goal and therefore the same priorities * To make sure ***no work goes to waste***, synchronization of the disciplines happens every sprint. * avoid one discipline getting too far ahead of the others! ## Self-management * No unnecessary management layers * Scrum teams are usually composed of 5 to 9 cross-disciplined developers who create vertical slices of major features every sprint. * How is this achieved? * Choose the amount of work to accomplish for the coming sprint and commit to it * Decide the best way to work together * Every Daily: Estimate your own work and monitor progress toward a committed goal * Every Sprint: Demonstrate sprint goals achieved to the stakeholders * Take responsibility for performance and find ways to improve it ## Self-organisation * Team selects their own members to complete tasks * Some sprints, like before release, might require a complete reorganization

* "Fully completed" should refer to ***completely releasable***