Skip to content

Scrum

What is scrum?

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

In a nutshell, Scrum fosters an environment where:

  1. A Product Owner orders (prioritises) the work for a complex problem into a Product Backlog.
  2. The Scrum Team turns a selection of the work into an Increment of value during a Sprint.
  3. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint.

Repeat

Scrum overview with entire process

Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managing, meaning they internally decide who does what, when, and how.

Roles at Partisia

Developers

Developers are the people in the Scrum Team that are committed to creating any aspect of a usable Increment each Sprint.

Developers are responsible for:

  • Planning the Sprint
  • Producing work
  • Adapting their plan each day toward the Sprint Goal
  • Presenting results at review

Product owner

The Product Owner is responsible for maximizing the value of the product resulting from the work of the Scrum Team.

The Product Owner is also responsible for effective Product Backlog management, which includes:

  • Developing and explicitly communicating the Product Goal
  • Creating and clearly communicating Product Backlog Features
  • Ordering Product Backlog (priorities and archiving features)
  • Ensuring that the Product Backlog is transparent, visible and understood

Scrum master

The Scrum Master is responsible for establishing Scrum as defined in the Scrum Guide (Partisia scrum guide). They do this by helping everyone understand Scrum theory and practice, both within the Scrum Team and the organization. The Scrum Master is responsible for the Scrum Team’s effectiveness

Events

Sprints takes 10-15 working days and contain the following events:

  • Sprint planning (1 hour) day 1
  • Scrum meetings (15 min) 5-10 times
  • Backlog refinement (ad hoc)
  • Sprint review (1 hour) final day
  • Retrospective (½ hour) final day

These events facilitate the empirical Scrum pillars of transparency, inspection, and adaptation.

Events are normally supported by online Google meetings and booked rooms.

Favro artifacts

We use the online tool Favro - intro video is located here.

Collections

  • Application (team)
  • Infrastructure (team)
  • Internal ( Internal projects )
  • PBC shared (with guests from Partisia Blockchain Applications)

Product Backlogs

  • Features
    • Category is an epic or a grouping
    • Feature is a single reviewable work unit that adds value for the customers and is divided into tasks as sub cards
  • Feature Requests
    • Feature is a requested but not yet prioritized feature
  • Bugs
    • Collection of cards that the team decides are bugs and can be worked upon

Sprint board columns

  • Selected: Cards selected from the backlog. This is usually done at the sprint planning
  • Doing: A member is working on task represented by the card
  • Review: Peers give feedback
  • Done: Ready to be confirmed by Product Owner at the sprint review

Lifecycle for tasks

  • Tasks start in the backlog
  • Moving a Card from backlog into the sprint board means it is planned with status Selected
  • When a task is moved into Done on the Sprint Board it is automatically updated in the backlog as well

Category denotes an epic or grouping in the backlog. Cards with the Category or Feature type are not intended for use on the Sprint Board.

Backlog refinement

Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size.

The Product Backlog

The Product Backlog should give an overview of what is needed to move the product towards the product goal. A Partisia Backlog is normally organized in the following categories:

  • Features
  • Feature requests
  • Bugs

Three top categories

Feature

In the features category we find product features defined by the Product Owner. A refined feature could have:

  • A description of who is the recipient, what she/he can do and why?
  • Suggestions for tasks that can be converted into cards
  • A priority based on the estimated value of the feature
  • Very high priority features are at the top of the features or category list
  • The team must agree on acceptance criteria before working on the feature and ensure this is clear from the description.

Card

At backlog refinement the developers break high priority features down in smaller Cards. These cards can be selected and worked on in the following sprints. A refined card should have:

  • A reviewable description of what is to be done
  • A complexity so the card can be solved and reviewed in 1-2 days
  • Dependencies or tags if it’s relevant
  • The type/status of card in the backlog
  • A task list or suggestions on how to solve the card if assigned to students

Normally a card follows the priority of the parent feature unless prioritized differently by the Product Owner.

After refinement

When a card is added to the sprint board at the sprint planning, its Members and Board status can be followed in the Backlog. Card after planning before work

When a card is done on the board, it is also shown as done in the Backlog, even when the done column is archived. Product Owner decides when the whole feature is done. Card when work is completing

Feature requests can be defined by all team members but have to be prioritized by the Product Owner.

Reference:

Official guide to scrum

https://scrumguides.org/scrum-guide.html