Demo

Also: Iteration Review, Sprint Review

A meeting, held at the end of an iteration, at which the development team demonstrates working software and solicits feedback from the product owner, the customer, management, other development teams and other project stakeholders. In Scrum, this meeting is called a Sprint Review.

Mike Cohn describes the format of a Sprint Review in his introduction to Scrum:

“The sprint review meeting is intentionally kept very informal, typically with rules forbidding the use of PowerPoint slides and allowing no more than two hours of preparation time for the meeting. A sprint review meeting should not become a distraction or significant detour for the team; rather, it should be a natural result of the sprint.”

In Scrum, the meeting is time boxed to no more than 5% of development time, i.e., one hour at the end of a one-week sprint.

Etymology:

Unknown.

Posted in d | 2 Comments

DevOps

Referring to the development of software systems, DevOps has been broadly defined as “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality”[1].

DevOps includes practices such as continuous integration, continuous automated testing, and automated deployment to ensure speed, quality, stability, and reliability.

DevOps is a cultural shift within many organizations. The historical separation between software development and IT operations is removed by having all participants contribute to the entire software development lifecycle. They are aligned around shared goals of fast delivery, high quality, and customer expectations.

Background of the term:

DevOps is a portmanteau of the two words development and operations that refer to software development and IT operations.

Further Learning:

What is DevOps?
https://devops.com/what-is-devops/


[1] DevOps: A Software Architect’s Perspective, 1st ed. by Bass, Weber, and Zhu.

Posted in d | Leave a comment

Done

See Definition of Done.

Posted in d | Leave a comment

Epic

A large user story that awaits decomposition into smaller stories prior to implementation. When an epic story works its way up the backlog, it is usually so decomposed. Epics are sometimes far off on the development horizon and have lower priority.

In the scrum framework stories that are sprint ready must be small enough that they can be confidently implemented within the timebox of a single sprint.

NB: One can easily be tempted to associate the term ‘epic’ with importance; in Agile, epic relates only to size.

Background of the Term

As it relates to agile methodologies, Mike Cohn coined the term epic in his book User Stories Applied: For Agile Software Development. Chapter 2 of that book is available here as a pdf, in which there is discussion of epics.

Further Learning:

Agile Alliance | Glossary | Epic
https://www.agilealliance.org/glossary/epic

Don’t Finish Your Epics! Deliver More Value Instead.
https://agilelearninglabs.com/2017/03/dont-finish-your-epics-deliver-more-value-instead/

User Stories Applied: For Agile Software Development
https://www.amazon.com/User-Stories-Applied-Software-Development/dp/0321205685/

Posted in e | 8 Comments

Evolutionary Development

See Iterative Development.

Posted in e | Leave a comment

Extreme Programming (XP)

An Agile software development methodology that emphasizes customer involvement, transparency, testing, and frequent delivery of working software.

The Extreme Programming canon includes a Customer Bill of Rights and a Developer Bill of Rights. Its core values are communication, simplicity, feedback, courage, and respect. XP is a developer-centric methodology. Unlike scrum, it prescribes specific coding practices like pair programming in which two developers work side by side at a single machine, automated unit testing, and frequent integration. Another key practice in XP is refactoring, or the continual internally-visible improvement of design and code.

The basic advantage of XP is that the whole process is visible and accountable. The developers make concrete commitments about what they will accomplish, show concrete progress in the form of deployable software, and when a milestone is reached they will describe exactly what they did and how and why that differed from the plan. This allows business-oriented people to make their own business commitments with confidence, to take advantage of opportunities as they arise, and to eliminate dead-ends quickly and cheaply. — Kent Beck

Background of the term

In 1996, Chrysler’s visionary CIO, Sue Unger, gave Kent Beck free rein to form a team to tackle the Chrysler Comprehensive Compensation payroll project. During this project Beck along with Ron Jeffries, Ward Cunningham, and Martin Fowler promoted and further developed the practices of what Beck called extreme programming.

Further Learning:

Agile Alliance | Glossary | Extreme Programming (XP)
https://www.agilealliance.org/glossary/xp

Extreme programming
https://en.wikipedia.org/wiki/Extreme_programming

Extreme Programming for Beginners made Easy – Roles & Practices
https://pm-training.net/extreme-programming-beginners/

Extreme Programming Explained: Embrace Change, 2nd edition. Kent Beck & Cynthia Andres.
https://smile.amazon.com/Extreme-Programming-Explained-Embrace-Change/dp/0321278658/

Posted in e | Leave a comment

Functional Test

See Acceptance Test.

Posted in f | Leave a comment

Impediment

In Scrum, any obstacle preventing a developer or team from completing work. One of the three focusing questions each member of a Scrum team answers during the daily Stand Up Meeting is: What impediments stand in your way?

Impediments may include such things as:

  • A meeting to attend
  • A lack of technical expertise.
  • A technical issue (eg, a network is down).

Scrum co-founder Ken Schwaber declared removing impediments to be “The ScrumMaster’s top priority” in his 2002 book, Agile Software Development with Scrum.

Etymology

Unknown.

Posted in i | Leave a comment

Incremental Delivery

See Iterative Development.

Posted in i | Leave a comment

Information Radiator

Also: Big Visible Charts

In Agile Software Development, the preferred way of displaying data visualizations is to post them on the wall in the team’s common workspace (i.e., rather than logging them in a spreadsheet). Examples of information radiators include a burn down chart, a burn up chart, and a task board, although other types of chart are possible. These may also be referred to as Big Visible Charts.

Keeping information visible at all times promotes transparency (one of the three legs of Scrum).

Etymology:

Alistair Cockburn coined the term “information radiator” in 2000, and introduced it in his 2001 book, Agile Software Development.

Posted in i | Leave a comment