Let's scrum

How we scrum at DiagRAMS technologies

Nicolas Froidure

Technical Leader @DiagRAMS
 

Crée des logiciels pour les startups innovantes dans les Hauts de France.

Vit dans le monde de Wayne.

 

Bloggue & Tweete à l'occasion.

Why scrum?

  • adapt to uncertain nature the IT projects
  • share progress regularly and on purpose
  • detect issues early

Sprint planning

Add issues to the sprint (matching the definition of ready).

Who's in?

  • Developers / Designers / Testers
  • Product owner
  • Scrum master

Expectations

  • The issues are prioritized in the backlog
  • Issues prioritized fulfills the definition of ready

Output

  • global goal
  • assigned tasks

Design review

Review issues and prioritize.

Who's in?

  • Product owner
  • Scrum master
  • 1 developer
  • 1 designer

Output

  • List of issues to refine
  • List of ready issues
  • Reordering of issues in the backlog

Sprint

Work on issues until reaching the definition of done.

Who's in?

  • Developers
  • Designers
  • Testers

Output

  • Release
  • Demo
  • Code
  • Designs

Poker planning

Define the CURSE of issues.

Who's in?

  • Developers
  • Designers
  • Testers
  • Scrum master

Output

  • List of issues to refine
  • List of issues to split
  • Ready issues estimates
  • If done remotely : #scrum-planning-poker

Daily standup

Sync with each others

Who's in?

  • Developers
  • Designers
  • Testers
  • Scrum master (observer)

Output

  • Pair programming meetings
  • A message in #scrum-daily-standup

Retrospective

Continuously improve the team's interactions.

Who's in?

  • Developers
  • Designers
  • Testers
  • Scrum master
  • Product owner

Output

  • List of fixing actions

Definitions

What needs to be done and how.

Definition of Ready

  • the feature is small enough to fit in one sprint,
  • every willed features are fully described into acceptance tests,
  • the UI/UX designs or at least the wire frames are ready (for dev task),
  • the user story has : explanatory title, a value proposition, one or more user roles attached,
  • the issue could be estimated in a poker planning.

Definition of Done : Design

  • the designed feature is fully covered,
  • loading and empty state are present,
  • the design reuse components,
  • new components are though to be reusable,
  • changed components are reevaluated in the context of all places where they were already used,
  • all behaviors are designed (hover, disabled, visited...),
  • keyboard focus is designed.

Definition of Done : Dev

  • tests must pass: unit, e2e, lint, types...
  • PR is squashed and rebased on the last master version, commits are conventional,
  • acceptance tests of the issue are checked, individually,
  • at least one coworker must have reviewed the code, run it locally and reviewed acceptance tests,
  • ensure your commit is self explanatory and describe the problem you try to solve in the pull request description,
  • link solved issues in your commit message,
  • the involved repositories definitions of done are also matched,
  • architecture choices are documented.

Useful resources