What are key agile concepts?

Daniel J. Power

Learning and understanding agile concepts is a starting point to becoming agile and collaborative as a project team member, team lead, coach or manager. An agile journey requires both an understanding of concepts and practice coupled with coaching. The words we use and how we use them is important. Agile vocabulary captures our intentions. So learn about agile, then do, then reflect, and then repeat.

A mindset, a way of thinking, a framework for action taking, a goal, and a journey to more contingent processes, higher performance, and potentially greater value creation. Agile means "able to move quickly and easily" or "ability to think and understand quickly". Agile is responsive to incomplete or changing requirements, provides short development cycles and rapid feedback, and facilitates more active customer involvement. Agile proponents argue other processes are too bureaucratic or cumbersome and that often too many things are done that are not directly related to a project outcome.

Agile development
A "time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end", cf.,

Agile organization
An organizing structure with decentralized decision making that is socially flat, team-oriented, and largely consensus-based. (Alistair Cockburn, CBTJ). The five trademarks of an Agile organization include 1) a network of teams within 2) a people-centered culture that 3) operates in rapid learning and fast decision cycles which are 4) enabled by technology, and a 5) common purpose that co-creates value for all stakeholders (see McKinsey, January 2018).

A capability created by structures, processes, and personnel to adapt, anticipate, and respond to ongoing technology and social disruption by using methods and processes that better meet market and customer demands. Agility is the ability of an organization to renew itself, adapt, change quickly, and succeed in a rapidly changing, ambiguous, turbulent environment. Agility is not incompatible with stability, rather agility requires stability. Aaron De Smet, McKinsey (December 2015) asserts agility needs two things. One is a dynamic capability, the ability to move fast—speed, nimbleness, responsiveness. And agility requires stability, a stable foundation—a platform, if you will—of things that don’t change.

Certain formalized and required meetings are traditionally part of an agile process including 1) Sprint planning meetings, 2) Daily Scrum, 3) Sprint review meetings, and 4) Sprint retrospective meetings. During these formal meetings specific tasks are required and completed.

Daily Meeting
Hold a fifteen-minute daily meeting for each team member to answer three questions: 1) "What have I done since the last team meeting? (i.e. yesterday)" 2) "What will I do before the next team meeting? (i.e. today)" 3) "What prevents me from performing my work as efficiently as possible?" The Coach or Scrum Master ensures that participants stay task focused. The Scrum literature recommends that this meeting occur as soon as all team members arrive at work.

Product Backlog
The product backlog (project backlog or task backlog) lists the needs, tasks, user stories and requirements for a project, expressed as a prioritized list of items. These items include both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product/project backlog, it is the sole responsibility of the product owner to prioritize the product backlog. The Product Backlog is an ordered list of the work to be done in order to create, maintain and sustain a product. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities. All items in the Product Backlog should add value to the customer. The Backlog is a living document in that it may and usually will change during the project life cycle. If there are new requirements, those needs should be added.

Product Backlog Item
In Scrum, a product backlog item ("PBI", "backlog item", or "item") is a unit of work small enough to be completed by a team in one Sprint iteration. Backlog items are decomposed into one or more tasks. The product backlog should not contain detailed, highly specific items and tasks.

Product Owner Role
One person must have final authority to represent the customer's interest in backlog prioritization and requirements questions. This person should be available to the team, but especially during the sprint planning meeting and the sprint review meeting. The product owner role varies between internally focused and externally client-focused projects. The development team should clearly identify the product owner in consultation with the project manager and client(s). With an external client, a member of the Scrum team acts on behalf of the key stakeholder and translates, requirements, user stories, etc. into a prioritized backlog that is shared with and approved by the client. A team lead may serve as the product owner surrogate. The challenges of being a product owner include: 1) Resisting the temptation to "manage" the team. The team may not self-organize in the way you would expect it to. This is especially challenging if some team members request your intervention with issues the team should sort out for itself. 2) Resisting the temptation to add more important work after a Sprint is already in progress. 3)Being willing to make hard choices during the sprint planning meeting. and 4) Balancing the interests of competing stakeholders.

Project Vision Statement
An ideal view of desired outcomes for the client with successful project completion. The vision statement is a vivid description of the project result to inspire the project beneficiaries to initiate the project and to guide the project team. A project vision answers the what and why questions and it provides a starting point for inspiring action.

Scrum Roles
There are three essential roles in any agile project: 1) Product Owner, 2) Scrum Master or Team Lead, 3) Team Member. On some agile teams, the “Scrum Master” may be called the Team Lead or team coach or project lead. The Team Lead is responsible for facilitating team tasks, interacting with the Product Owner, obtaining resources for the team, and protecting team members from external interference.

Scrum Master Role
The Scrum Master is a facilitator for the team and product owner. Rather than manage the team, the Scrum Master works to assist both the team and product owner in the following ways: a) Remove the barriers between the development and the product owner so that the product owner directly drives development. b) Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. c) Improve the lives of the development team by facilitating creativity and empowerment. d) Improve the productivity of the development team in any way possible. e) Improve practices and tools so that each increment of functionality is potentially shippable. f) Keep information about the team's progress up to date and visible to all parties. Source: Agile Project Management with Scrum, Ken Schwaber

The management principle that teams autonomously organize their work. Self-organization happens within boundaries and against given goals. Teams choose how best to accomplish their work, rather than being directed by others outside the team.

An iteration of work during which an increment of product functionality is implemented. By the book, an iteration lasts 30 days. This is longer than in other agile methods to take into account the fact that a functional increment of product must be produced each sprint. The sprint starts with a one-day sprint planning meeting. Many daily Scrum meetings occur during the sprint (one per day). At the end of the sprint we have a sprint review meeting, followed by a sprint retrospective meeting. During the sprint, the team must not be interrupted with additional requests. Guaranteeing the team won't be interrupted allows it to make real commitments it can be expected to keep.

Sprint Backlog
Defines the work for a sprint, represented by the set of tasks that must be completed to realize the sprint's goals, and selected set of product backlog items.

Sprint Goals
Sprint goals are the result of a negotiation between the product owner and the development team. Meaningful goals are specific and measurable. Instead of "Improve scalability" try "Handle five times as many users as version 0.8." Scrum focuses on goals that result in demonstrable product. The product owner is entitled to expect demonstrable product (however small or flimsy) starting with the very first Sprint. In iterative development, subsequent Sprints can increase the robustness or size of the feature set.

Sprint Planning Meeting
The Sprint planning meeting is a negotiation between the team and the product owner about what the team will do during the next sprint. The product owner and all team members agree on a set of sprint goals, which is used to determine which product backlog items to commit from the uncommitted backlog to the sprint. Often new backlog items are defined during the meeting. This portion of the sprint planning meeting is time-boxed to four hours.

Sprint Retrospective Meeting
A sprint retrospective meeting is held at the end of every sprint following the sprint review meeting. The team and ScrumMaster meet to discuss what went well and what to improve in the next sprint. The product owner does not attend this meeting. The sprint retrospective should be time-boxed to three hours.

Sprint Task
In Scrum, a sprint task (or task) is a unit of work from the backlog. Team members volunteer for tasks. They update the estimated number of hours remaining on a daily basis, influencing the sprint burndown chart. Tasks are contained by backlog items.

A person external to an agile team with a specific interest in and knowledge of a product/project. Stakeholders are represented by the Product Owner and who actively engages with the Team at Sprint Review.

User stories
One of the primary development artifacts for Scrum and Extreme Programming (XP) project teams. A user story is a very high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it. A user story is a unit of work that should be completed in one sprint. A user story helps to create a simplified description of a requirement. In agile Scrum, a User story is a description of an objective that helps a person to achieve a feature. A user story usually has three main parts, a System Actor, an Action, and the desired Achievement. The Achievement is what the actor wants to achieve by performing the action. For information on writing them see

Value-Driven Delivery
Agile processes emphasize the early delivery of value. Value-driven delivery is the main focus and goal of sprints. A major goal on an agile project is the delivery of maximum business value in the minimum span of time. A team focuses on delivering the results defined in the Project Vision Statement and overcoming constraints of time, cost, scope, quality, people, and organizational capabilities to deliver value. Team members should understand what adds value to customers and users and then prioritize the high-value requirements at the top of the Product Backlog.


Last update: 2019-06-20 10:18
Author: Daniel Power

Print this record Print this record
Show this as PDF file Show this as PDF file

Please rate this entry:

Average rating: 0 from 5 (0 Votes )

completely useless 1 2 3 4 5 most valuable

You cannot comment on this entry

DSS Home |  About Us |  Contact Us |  Site Index |  Subscribe | What's New
Please Tell Your Friends about DSSResources.COMCopyright © 1995-2015 by D. J. Power (see his home page).
DSSResources.COMsm is maintained by Daniel J. Power. Please contact him at with questions. See disclaimer and privacy statement.


powered by phpMyFAQ 1.5.3