Velocity

Velocity is a measure of done Backlog Items delivered per Timebox (Iteration or Cycle). It is used to provide a forecast of future done work. Conditions are that the team and the timebox are stable over time.

Calculating Velocity

It is possible to calculate the Velocity of a Team for a single Iteration or Cycle. For better results we sum ip all “done” work of all timeboxes, measured in Story Points  (SP), and divide them by the number of timeboxes. This results in the mean Velocity over time.

 

Application of Velocity

  • Working Teams use it to calculate how much work to pull into the Iteration Backlog within Iteration Planning meetings. For better results it is typically normalized by non-regular absences like holidays and planned absences.
  • Product Owners use it to predict milestones and release dates of products.

\r\n


Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

.

Cluster Planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

.

Portfolio Planning

Organisation Sync

Portfolio Refinement

Portfolio Review

Organisation Retrospective

Team Product Owner

Team System Engineer

Team Scrum Master

.

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

.

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Working Team

Community of Practice

.

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

.

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

.

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

.

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Organisation Improvement Backlog

Team Review

At the end of each iteration, an Team Review is held in which the Team presents the results to the Stakeholders, with the Team receiving feedback from the Stakeholders and then jointly adjusting the Team Backlog when needed. Together with any changes to Team Backlog during the past Iteration (within the Team Backlog Refinement meetings), these provide the basis for the work on possible new value-added items. The Team Review is an informal meeting, not a status report. The demonstration of the results is intended as a stimulus for feedback and the basis for cooperation. At the end of the Team Review, the Product Owner may present an update on costs and scheduled dates or milestones.

For a four-week Iteration, an upper limit of four hours is used as the timebox for this meeting. For shorter Iterations, a shorter timebox is used. The Team Scrum Master ensures that the event takes place and the participants understand its purpose. The Team Scrum Master teaches all participants to complete the event within the given timebox.

The Team Review includes the following elements:

  • The participants, consisting of the Team and the Stakeholders invited by the Product Owner.
  • The Product Owner explains which Team Backlog entries are done.
  • The Working Team explains what went well during the Iteration, what Impediments and problems arose, and how the Team solved those. If necessary, the Team asks for support from the Stakeholders regarding Impediments
  • The Working Team presents the “done” work results and answers questions. Work results can be:
    • Inspectable Results,
    • Usable Knowledge,
    • an integrated sample of the System, Platform or Application
  • The Product Owner presents the current status of the Team Backlog. If required, he provides an updated forecast of delivery dates based on the development progress, e.g. by using a Burn-up-Chart based on the Velocity of the Team
  • All participants work together on what to do next so that the Product Owner gets valuable input for the upcoming Team Planning.
  • All participants reviews the schedule, budget, potential properties, and market expectations for the next version of the System or Application (aka Release).

The result of the Team Review is a reworked Team Backlog that matches the participants’ common knowledge and allows the Team to work on the highest value Team Backlog Items in the next Iteration. The Team Backlog can also be extensively redesigned to take advantage of new opportunities.

.

\r\n


Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Backlog Refinement

Team Retrospective

.

Cluster Review

.

Portfolio Review

Team Product Owner

Team System Engineer

Team Scrum Master

Working Team

Community of Practice

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

 

Team Planning

Iteration Planning (Scrum)

Each Iteration begins with the Team Planning event of the Team. Here, the Team Product Owner presents the Working Team with the current state of the Team Backlog. New entries or changes that are not yet known to the Working Team since the last Team Backlog Refinement are estimated, and if necessary supplemented by Acceptance Criteria and prioritized by the Team Product Owner within the Team Backlog.
The Working Team determines the capacity for the next Iteration by looking at the team’s previous work rate (Team Velocity) and filling the Team Calendar, which shows the time that each Team Member can spend for the Working Team.
The Working Team pulls the number of TBIs into the Iteration Backlog that matches the teams capacity for the next Iteration. Afterwards the Working Team refines the TBIs by creating Tasks, depending on the complexity.

Then, the Working Team starts the Iteration by pulling the first Tasks (or TBIs) from “open” to “in progress”.

Continuous Team Planning (Kanban-mode)

As an alternative to the planning rhythm in Iterations, the planning of work for the team can also be done continuously. This is done during, the Team Backlog Refinements, whereby the work on a Team Backlog Item can be started directly after the analysis and estimation.

\r\n


Further suitable links:

Events Roles Groups Artifacts
Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

.

Cluster Planning

.

Portfolio Planning

Team Product Owner

Team System Engineer

Team Scrum Master

Working Team

Community of Practice

Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog