yunity Scrum

This version of yunity Scrum was introduced by Douglas Webb and was evaluated during the Rotterdam WuppDays 2016-03-21 to 2016-04-11 with 2 sprints. Evaluation results are pending.

yunity is trying out Scrum as a framework for the product (web application) work flow. Our version of Scrum is very similar to the version outlined by Schwaber and Sutherland - founders of Scrum - in 'The Scrum Guide'. A lot of the content in this article is copy/pasted from the guide (italics) and at only 16 pages and well worth reading for a deeper understanding.

Scrum is a framework which is;

  • light - Scrum is pretty minimal and many other techniques and tools can be added in.

  • based on empiricism - Decisions made on experimental experience, not reasoned logic.

  • Incremental - The product is not released in one go, but built steadily in installments.

  • Iterative - The Scrum cycles repeats again and again.



The yunity Scrum framework consists of Scrum Teams and their associated roles, events, artifacts and rules.




The Scrum Team

The scrum team consists of the product team, the development team and the scrum facilitator.

The Product Team

Figures out what the product should be, responsible for maximizing the value of the product and the work of the Development Team. In 'pure Scrum', a single 'product owner' would have this role, but we have decided to share this responsibility between several individuals. Currently: Martin Schott, Raphael Fellmer, Nick Sellen, Matthias Larisch and Tilmann

The Development Team

Creates the product, consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Our team includes both developers and designers and is not limited to a maximum of 9 people as outlined in 'pure Scrum'. Currently: Nick Sellen, Tilmann, Matthias Larisch, Neel Peters, Zed Redstone, Pranav Salunke, Tess, Manuele Carlini, Vinicio De Angelis, Manuel Waelder

The Scrum Facilitator

Facilitates the framework, responsible for ensuring Scrum is understood and enacted. Currently: Douglas Webb

Scrum Events

Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration. Once a Sprint begins, its duration is fixed and cannot be shortened or lengthened.

The Sprint

A stretch of planned work between one week and one month, The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created. Sprints best have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint. Current sprints are one week long.

Sprint Planning

The whole Scrum team meets to decide the work for the upcoming sprint. The specification owner brings forward their desires for the sprint and the product team select what they can do. Te following questions are addressed;

  • What can be delivered in the Increment resulting from the upcoming Sprint?
  • How will the work needed to deliver the Increment be achieved?

Resulting in the sprint backlog and a sprint goal. Current Sprint Planning meetings are 60 minutes long

Daily Scrum

Daily meeting to coordinate the efforts of the Product Team, Development Team members explain:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Current Daily Scrums are 15 minutes long.

Sprint Review

Analysis of work, Scrum Team and stakeholders collaborate about what was done in the Sprint. Current Sprint Reviews are 30 minutes long.

Sprint Retrospective

Analysis of process,

  • Inspect how the last Sprint went with regards to people, relationships, process, and tools;
  • Identify and order the major items that went well and potential improvements; and,
  • Create a plan for implementing improvements to the way the Scrum Team does its work.

Current sprint retrospectives are 30 minutes long.

Scrum Artifacts

Product Backlog

Prioritized list of all the product features, the single source of requirements for any changes to be made to the product. A Product Backlog is never complete. This is created an maintained by the product team with help from stakeholders (i.e. everyone in the project, but mostly devs)

Sprint Backlog

List of intended work for sprint, the set of Product Backlog items selected for the Sprint. This is created during the Sprint Planning, with the final say from the Development team.


The work done, the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.

Concretely, the increment consists of the output of all teams involved in the yunity Scrum process: 


Last review on 2016-03-31 by Nick Sellen