Iteration Burn Down

See Burn Down Chart.

Posted in i | Leave a comment

Iteration Demo

See Demo.

Posted in i | Leave a comment

Iteration Review

See Demo.

Posted in i | Leave a comment

Iterative Development

Also: Incremental Delivery, Evolutionary Development, Timeboxing

A project life-cycle strategy used to reduce risk of project failure by dividing projects into smaller, more manageable pieces of “potentially shippable” product delivered over the course of a series of brief iterations, or sprints. Iterative development  processes afford teams the ability to “inspect and adapt” their processes between iterations, leading to continuous improvement. The concept of iterative development stands in contrast to the traditional, waterfall method of “big design up front” followed by development and testing in strict sequence.

The concept of iterative development is central to all Agile fameworks, and is treated as essentially synonymous with Agile development. Extreme Programming recommends that teams make frequent, small releases, working in iterations of one to four weeks, with one week being the preferred interval. Scrum also recommends regular cycles, called sprints, of one to four weeks.

Etymology

The concept of iterative software development was first described by Tom Gilb in his 1988 book, Principles of Software Engineering Management, where he referred to it as Evolutionary Development. It has gone on to permeate all Agile frameworks.

Posted in i | 3 Comments

On Site Customer

See Product Owner.

Posted in o | Leave a comment

Persona

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 null suggesting that the idea of “typical” needed to be dropped, and teams should design a product for an individual persona.

References

null by Alan Cooper

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

Posted in p | Leave a comment

Planning Poker

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.

Posted in p | Leave a comment

Principles

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.

Posted in p | Leave a comment

Product Backlog

See Backlog.

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-coding 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 it’s 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.

Certified Scrum Product Owner is a professional designation offered by the Scrum Alliance, obtained by completing a two day introductory course and passing a one hour exam.

Etymology

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.

Posted in p | Leave a comment