Product Backlog

See Backlog.

Posted in p | Leave a comment

Product Goal

The 2020 Scrum Guide introduced the product goal. It is one of three commitments associated with scrum artifacts and is the commitment for the Product Backlog artifact.

“A product is the vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users, or customers. A product could be a service, a physical product, or something more abstract.

The Scrum Guide, 2020, Ken Schwaber & Jeff Sutherland

Essential aspects of products goals

  • They must be a distinct end product and written down
  • They reflect market demand and are not driven by what is in the backlog
  • The team works on one product goal at a time.
    1. One can lead to another but they are written in a way that the team can achieve one goal at a time.
  • The goal is the end result and not a design document.
    1. The team decides how to achieve the goal.

Background Of The Term

Ken Schwaber and Jeff Sutherland introduced the product goal to add commitments for each of the three scrum artifacts: product backlog, sprint backlog, and increment.

Further Learning

InFoQ article – Changes in the 2020 Scrum Guide: Q&A with Ken Schwaber and Jeff Sutherland
Scrum Alliance Blog – Product Goal

Posted in p | Leave a comment

Product Owner

Also: Customer, On Site Customer

On an agile development team, the real customer or end user, or a stand-in for the customer or end user; a non-developer team member who has a complete grasp of the requirements and business value of the product and is responsible for prioritizing work for the team.

The Product Owner is the primary author of the user stories, owns the product backlog, prioritizes the stories, writes acceptance tests, and accepts work completed by the team. On some teams, the product owner may act as a liaison between stakeholders and the team, communicating the vision of the product while ensuring the team stays on track to meet the customer’s goals. On other teams, typically involving larger projects, this role may be played by a Product Manager. In Extreme Programming, the preference is for the On Site Customer to be an actual customer, not a stand-in.

Agile coach Simon Baker elegantly describes the role of the Product Owner: “You must recognize that through your actions – writing user stories and acceptance tests, prioritizing user stories by business value, deciding which user stories are developed next, providing rapid feedback, etc – you are effectively steering the project and are ultimately responsible for the business value that is delivered. As the driving force behind the project your presence must be visible, vocal and objective.”

Tip: Some agilists enjoy referring to the Product Owner as the “single wringable neck” on a team—the person who bears responsibility for the team’s failure to meet its sprint or release goals. However, there is a great deal of disagreement in the professional community as to whether this notion is truly agile, so we do not consider this level of ultimate responsibility to be native to the role’s core definition.

Background Of The Term

The term Product Owner is commonly used across agile frameworks, but is native to scrum. In Extreme Programming, the role is referred to as Customer, or On Site Customer.

Further Learning

Product Owner – Agile Alliance glossary
Product Owner – The 2020 Scrum Guide
What is a Scrum Product Owner – Agile Learning Labs blog post

Posted in p | Leave a comment

Release Backlog

See Backlog.

Posted in r | Leave a comment

Release Burn Down

See Burn Down Chart.

Posted in r | 1 Comment


See Sprint Retrospective

Posted in r | 2 Comments


A lightweight framework to help people, teams, and complex organizations develop value through adaptive solutions for complex problems. Scrum is the most widely recognized Agile framework and is compatible with other agile practices like Extreme Programming and test-driven development.

Scrum is comprised of a series of short iterations–called sprints–each of which ends with the delivery of an increment of business value. A simple way to remember all the key elements of Scrum is this; “3” roles, “5” events, and “3” artifacts. The 3 roles are: Product Owner, Developers, and Scrum Master. Scrum counts on a Scrum Master to foster an environment where: Product Owners sequence complex problems into a backlog, Developers work on sequenced product backlog items and deliver business value after a sprint, and Developers and Stakeholders take note of their delivery approach during a sprint and look to make improvements for the following sprint. The 5 events that are time-boxed: sprint planning, daily scrum, sprint, sprint review, and sprint retrospective. The 3 artifacts are: product backlog (product goal), sprint backlog (sprint goal), and the product increment (definition of done).

Scrum is deliberately incomplete. Rather than provide people with precise instructions, the rules of Scrum help guide their relationship and interactions. Scrum is not a process, technique, or a definitive method. Scrum is simply a framework and within the framework we may apply various process and or techniques.

Tip: You will sometimes hear the term scrum used interchangeably with the term agile, but this is incorrect. Agile is not a framework, but a broader set of values and practices, while scrum is a specific framework that fits comfortably under the agile umbrella.

Background Of The Term

The term “scrum,” as it is commonly applied to software development, began its life as a sports metaphor. The term “scrum” derives from the game of rugby, where it refers to a team that moves down the field as one body.  Scrum was first introduced as a metaphor for industrial processes in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka, two Japanese academics who used it to describe a new, flexible approach in a paper titled “The New New Product Development Game.

In the early 90’s, several complimentary events conspired to bring the term “scrum” into use within agile development community. In 1990 Peter DeGrace and Leslie Hulet Stahl published a book called “Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms,” which contained a blistering critique of the commonly accepted “waterfall” method for software development. DeGrace and Hulet Stahl quoted Takeuchi and Nonaka’s paper as a possible remedy.  Influenced by this popular work, a team of software developers, Jeff Sutherland, John Scumniotales, and Jeff McKenna, used the term scrum to describe a new framework they had begun to develop in accordance with the values and principles of the Agile Manifesto. In parallel, Ken Schwaber was developing a similar framework at his company, Advanced Development Methods.

The two teams were aware of each other’s work, and in 1995, Schwaber and Sutherland jointly authored a paper that laid out the basics of a framework they dubbed scrum. Schwaber later collaborated with Mike Beedle on the book Agile Software Development with Scrum. Schwaber went on to found the Scrum Alliance, which is now the certifying body for scrum trainers and practitioners of all levels, and the primary source of authoritative information on the state of scrum as practiced today.

Further Learning

The Scrum Guide – by Ken Schwaber & Jeff Sutherland

Scrum Overview – by Scrum Alliance

Intro to the Scrum Framework – by Scrum Inc.

Posted in s | 8 Comments

Scrum Artifacts

Scrum’s artifacts are listed in the 2020 Scrum Guide. They represent the work the team does and the business value of the product.

Each artifact contains a commitment with enough information that the commitment can be measured. The commitments are:

These commitments reinforce the philosophy that agile goals develop from team experience and history.

Posted in s | Leave a comment

Scrum Board

See Task Board.

Posted in s | Leave a comment

Small Release

See Iteration.

Posted in s | Leave a comment