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 of the innovative projects
  • share progress regularly and on purpose
  • detect issues early

Scrum Manager

  • Each sprint gets a new scrum manager
  • Prepare, manage and report meetings
  • Ordering: the new scrum manager starts with a poker planning, then a design review, the sprint planning, the demo and finally a retrospective

Release Manager

  • Each sprint gets a new release manager
  • Prepare, check and deploy new versions
  • Synchronize versions with devs

Sprint planning

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

Who's in?

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


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


  • global goal
  • assigned tasks

Design review

Review issues and prioritize.

Who's in?

  • Product owner
  • Scrum manager
  • 1 developer
  • 1 designer


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


Work on issues until reaching the definition of done.

Who's in?

  • Developers
  • Designers
  • Testers


  • Release
  • Demo
  • Code
  • Designs

Poker planning

Define the CURSE of issues.

Who's in?

  • Developers
  • Designers
  • Testers
  • Scrum manager


  • 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 manager (observer)


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


Continuously improve the team's interactions.

Who's in?

  • Developers
  • Designers
  • Testers
  • Scrum manager
  • Product owner


  • List of fixing actions


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, give the commands necessary to test,
  • link solved issues in your commit message,
  • the involved repositories definitions of done are also matched,
  • architecture choices are documented.

Useful resources

Made with Slides.com