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

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

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 manager (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 manager
• 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, 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.