The Agile Dictionary

Also: User Persona

A fictional character with individual needs, goals and habits, created by an Agile team as a representative user, to serve as a reference-point for usability during product development. Agile teams may refer back to a set of personas (the convention is to use the English plural rather than the latin personae) as they develop a product, to test whether or not the product meets these users’ needs and desires.

Etymology

The concept of using actual characters to represent “typical users” dates back to advertising giant Ogilvy, which included the concept in their “knowledge management system” in 1997. Agilist Alan Cooper took the concept one step further in his 1999 book The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity suggesting that the idea of “typical” needed to be dropped, and teams should design a product for an individual persona.

References

The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity by Alan Cooper

Personas, Profiles, Actors, & Roles: Modeling users to target successful product design an interactive presentation by Jeff Patton

An estimating tool in Agile, Planning Poker is a structured game used to reach group consensus while estimating tasks. It is called poker because it does indeed involve a deck of cards.

Game Play: Each card in the deck is inscribed with a number in the Fibonacci sequence, in which each number is equal to the sum of the previous two: 1, 2, 3, 5, 8, 13, 21, etc. Team members each choose a card that represents their best guess as to the difficulty level of the task, and everyone turns over their cards at once. The high and low cards get the floor to argue their cases, and after that, the game is repeated, the theory being that the players’ estimates will converge through rounds of structured discussion. A Project Manager or Scrum Master may serve as moderator.

Etymology

The game was first created by Agile consultant James Grenning, an original signator to the Agile Manifesto, in 2002, while working with an XP Team. It was later popularized by Agile consultant and Certified Scrum Trainer Mike Cohn, in his book, Agile Estimating and Planning.

Also: Agile Principles

The Agile Principles, like the Agile Values, were first stated by a group of independent software development pundits who gathered at the Snowbird resort in Utah in 2001 in order to codify the their shared philosophy. The result was an Agile Manifesto, the signatories to which formed the basis of the Agile Alliance. The Manifesto consisted of a set of Values, and their supporting principles. The twelve principles are listed below:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Etymology

The Agile Principles were originally stated in the Agile Manifesto.

See Backlog.

Product discovery is the iterative work of figuring what will make a product usable, useful, valuable, and implementable.

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

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