Copy of Development process

Käesoleva dokumendi eesmärgiks on kirjeldada, kuidas me koostööd teeme oma teenuse arendamisel.

Events Schedule

  • Sprint planning meeting - esmaspäev - 09:00 - 09:30

  • Daily Scrum - 09:33 - 09:48

  • Sprint Review - reedel kell 14:00 - 14:30

  • Sprint retrospective - reedel kell 14:30 - 14:45

Roles

  • Product Owner - Heiti

  • Development Team - Andrei, Margus, Kristi

  • Scrum Master - Andres

Artifacts

Definition of “Done”

When a Product Backlog item or an Increment is described as “Done”, everyone must understand what “Done” means. Although this may vary significantly per Scrum Team, members must have a shared understanding of what it means for work to be complete, to ensure transparency. This is the definition of “Done” for the Scrum Team and is used to assess when work is complete on the product Increment.

  1. ….

  2. ….

  3. …..

Roles

  • The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

    • Clearly expressing Product Backlog items;

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

    • Optimizing the value of the work the Development Team performs;

    • Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what

      the Scrum Team will work on next; and,

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

      needed.

  • The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint.

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

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

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

  • The Scrum Master serves:

    • the Product Owner in several ways, including:

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

      • Finding techniques for effective Product Backlog management;

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

      • Understanding product planning in an empirical environment;

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

      • Understanding and practicing agility; and,

      • Facilitating Scrum events as requested or needed.

    • the Development Team in several ways, including:

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

      • Helping the Development Team to create high-value products;

      • Removing impediments to the Development Team’s progress;

      • Facilitating Scrum events as requested or needed; and,

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

Events

The Sprint

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 have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of:

  • the Sprint Planning,

  • Daily Scrums,

  • the development work,

  • the Sprint Review,

  • the Sprint Retrospective.

During the Sprint:

  • No changes are made that would endanger the Sprint Goal;

  • Quality goals do not decrease; and,

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

Sprint Planning

The work to be performed in the Sprint is planned at the Sprint Planning. This plan is created by the collaborative work of the entire Scrum Team.

Sprint Planning answers the following:

  • What can be delivered in the Increment resulting from the upcoming Sprint?

  • How will the work needed to deliver the Increment be achieved?

The input to this meeting is the Product Backlog, the latest product Increment, projected capacity of the Development Team during the Sprint, and past performance of the Development Team. The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.

Having set the Sprint Goal and selected the Product Backlog items for the Sprint, the Development Team decides how it will build this functionality into a “Done” product Increment during the Sprint. The Product Backlog items selected for this Sprint plus the plan for delivering them is called the Sprint Backlog.

Sprint Goal

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint.

Daily Scrum

The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours. This optimizes team collaboration and performance by inspecting the work since the last Daily Scrum and forecasting upcoming Sprint work. The Daily Scrum is held at the same time and place each day to reduce complexity.

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

Sprint Review

A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint.

The Sprint Review includes the following elements:

  • Attendees include the Scrum Team and key stakeholders invited by the Product Owner;

  • The Product Owner explains what Product Backlog items have been “Done” and what has
    not been “Done”;

  • The Development Team discusses what went well during the Sprint, what problems it ran
    into, and how those problems were solved;

  • The Development Team demonstrates the work that it has “Done” and answers questions
    about the Increment;

  • The Product Owner discusses the Product Backlog as it stands. He or she projects likely
    target and delivery dates based on progress to date (if needed);

  • The entire group collaborates on what to do next, so that the Sprint Review provides
    valuable input to subsequent Sprint Planning;

  • Review of how the marketplace or potential use of the product might have changed what is
    the most valuable thing to do next; and,

  • Review of the timeline, budget, potential capabilities, and marketplace for the next
    anticipated releases of functionality or capability of the product.

The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog items for the next Sprint. The Product Backlog may also be adjusted overall to meet new opportunities.

Sprint Retrospective

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

The purpose of the Sprint Retrospective is to:

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

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint.

Scrum Artifacts

Scrum’s artifacts represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts defined by Scrum are specifically designed to maximize transparency of key information so that everybody has the same understanding of the artifact.

Product Backlog

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Sprint Backlog

The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.

Increment

The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints. At the end of a Sprint, the new Increment must be “Done,” which means it must be in useable condition and meet the Scrum Team’s definition of “Done.”