Introduction to agile development and scrum

Notes on some topics are omitted as they were also covered in places such as Introduction to DevOps.

Introduction

  • Principles

    • Individuals and interactions over processes and tools

    • Working software over comprehensive documentation

    • Customer collaboration over contract negotiation

    • Responding to change over following a plan

  • Scrum

    • Uses fixed-length (~2 week) iterations called sprints

    • Each sprint should produce a shippable increment

    • Steps

      • Plan the sprint and produce a sprint backlog

      • Daily scrum meetings

      • Sprint execution (do the work)

      • Sprint review (present the work and gather feedback)

      • Sprint retrospective (reflect on the sprint and identify areas for improvement)

      • Backlog refinement/grooming

      • Sprint closure

    • Roles

      • Product owner

        • Represents stakeholder interests

        • Articulates the vision

        • Defines and prioritizes the backlog

      • Scrum master

        • Facilitates the process

        • Removes impediments

        • Shields the team from external interference

        • Ideally not the team's manager

      • Scrum team/development team

        • The team should be self-organizing

        • Individual members choose tasks to work on from the sprint backlog

    • Artifacts

      • Product backlog

      • Sprint backlog

      • Done increment

  • Kanban

    • Uses a continuous flow

    • Continuous delivery

    • No defined roles

    • Measures cycle time rather than velocity

    • Tasks can be changed at any time rather than being fixed for the duration of a sprint

  • Teams should be loosely coupled but tightly aligned

  • Each team should have its own business-aligned mission and own the end-to-end process, acting like a mini-startup

  • Unsurprisingly, sticking sprints in the development part of a waterfall plan is not agile, despite what many companies claim

Planning

  • You can't plan everything upfront as that's when you know the least

    • There was a "navigating through penguins" analogy, which was better than I expected given the premise

  • Don't just naively translate traditional roles to Scrum

    • Product managers are not product owners

    • Project managers are not scrum masters

    • Development teams are not scrum teams

  • Consider ZenHub, which allows you to integrate project-management functionality with GitHub

  • Stories

    • Description of the need and business value

    • Any details/assumptions

    • A definition of "done"

  • If it would be too big for a single sprint then it would be an epic instead

  • Backlog items tend to be epics, which can then be broken down into stories for a sprint

  • Story points

    • Abstraction measuring how big a task is in terms of effort, complexity, and uncertainty

    • Think t-shirt sizes (is this small? medium? large?) rather than specific time estimates

    • Often based on Fibonacci numbers

    • It can be useful to have a reference story (e.g., a medium-sized story that you've scored as a five)

  • Refining the backlog

    • Rank by priority

    • The highest-priority stories should be broken down into ones small enough to fit in a sprint

    • Can be useful to have a dev representative present when refining in addition to the product owner and scrum master

  • Team velocity is the number of story points per sprint

Execution

  • Developers should assign themselves the highest-priority story from the sprint backlog that is appropriate for them

  • You shouldn't have more than one story at once unless you're blocked

  • Daily scrums are not a status update for the product owner; the product owner can be there to answer questions, but they're not there to ask them

  • Each person's update covers

    • What did I do yesterday?

    • What will I do today?

    • Are there any blockers?

  • Discussion of any new topics should wait until after the meeting

  • Burndown charts show how the proportion of the story points that have been completed changes over time

  • The sprint review is a demo for the product owner and stakeholders

  • The sprint retrospective answers three questions

    • What went well?

    • What didn't go well?

    • What should we change for the next sprint?

  • The retrospective should usually be limited to the scrum master and the development team

Last updated