SCRUM

BASICS

Scrum is founded on empirical process control theory, or empiricis.

The essence of Scrum is a small team of people.

The individual team is highly flexible and adaptive. These strengths continue operating in single, several, many, and networks of teams that develop, release, operate and sustain the work and work products of thousands of people.

Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.

3 pillars

Inspection

Adaptation

Transparency

common standard

common understanding

common language

Definition of Done - common for the one who is performing the work and the one who is accepting the work

Significant aspects of the process must be visible to those responsible for the outcome.

Inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.

Inspection should not be so frequent that inspection gets in the way of the work.

If resulting product will be unacceptable, the process or the material being processed must be adjusted.

4 formal evens for inspection:

Codzienny Scrum (ang. Daily Scrum)

Przegląd Sprintu (ang. Sprint Review)

Planowanie Sprintu (ang. Sprint Planning)

Retrospektywa Sprintu (ang. Sprint Retrospective)

5 values of scrum

openness

respect

focus

commitment

courage

TEAM

Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available.

click to edit

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.

Scrum Master

Zespół Deweloperski (ang. Development Team)

Właściciel Produktu (ang. Product Owner)

self-organizing and cross-functional

The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Clearly expressing Product Backlog items

Ordering the items in the Product Backlog to best achieve goals and missions

responsible for managing the Product Backlog

Optimizing the value of the work the Development Team performs

is responsible for maximizing the value of the product resulting from work of the Development Team

Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next

Ensuring the Development Team understands items in the Product Backlog to the level needed

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment

Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person

Only members of the Development Team create the Increment.

Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis

Development Team consists of professionals who do the work of delivering a Increment of "Done"

Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole

Having more than nine (9) members requires too much coordination

Leading and coaching the organization in its Scrum adoption

Planning Scrum implementations within the organization

is a servant-leader for the Scrum Team

Helping employees and stakeholders understand and enact Scrum and empirical product development

helping everyone understand Scrum theory, practices, rules, and values.

Causing change that increases the productivity of the Scrum Team

is responsible for promoting and supporting Scrum as defined in the Scrum Guide

Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization

SCRUM MASTER SERVICE

Helping the Development Team to create high-value products

Coaching the Development Team in self-organization and cross-functionality

Removing impediments to the Development Team’s progress

Facilitating Scrum events as requested or needed

Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood

SCRUM MASTER SERVICE

Understanding product planning in an empirical environment

Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value

Helping the Scrum Team understand the need for clear and concise Product Backlog items

Finding techniques for effective Product Backlog management

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible

Understanding and practicing agility

Facilitating Scrum events as requested or needed

Scrum Events

SPRINT

a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created

Sprints contain

During the Sprint:

CANCELATION

Daily Scrums

development work

Sprint Planning

Sprint Review

Sprint Retrospective

Quality goals do not decrease

Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned

No changes are made that would endanger the Sprint Goal

Longer than one month can

complexity may rise

the definition of what is being built may change

risk may increase

Only the Product Owner has the authority to cancel the Sprint

may do so under influence from the stakeholders, the Development Team, or the Scrum Master

A Sprint would be cancelled if the Sprint Goal becomes obsolete. This might occur if the company changes direction or if market or technology conditions change. In general, a Sprint should be cancelled if it no longer makes sense given the circumstances.

When a Sprint is cancelled, any completed and "Done" Product Backlog items are reviewed. If part of the work is potentially releasable, the Product Owner typically accepts it. All incomplete Product Backlog Items are re-estimated and put back on the Product Backlog. The work done on them depreciates quickly and must be frequently re-estimated.