Agile methodology

An Agile methodology (alternatively known as Agile development and, when applied to software development, Agile Software Development) is a product development framework that is based on development of deliverable increments in frequent iterations based on evolving requirements.

This project administration approach is founded on developing the deliverable in frequent iterations based on the requirements that evolve based on the results of previous iterations. The Agile methodology is characterized by frequent reassessment and adaptation of initial objectives. Instead of once-defined projects in the Waterfall model, the Agile methodology encourages continuous re-definition based on continuous feedback. This feature makes the Agile methodology instrumental in those developments that are as inherently unpredictable as most of the career projects are.

Definitions

According to the Agile Extension to the BABOK Guide (preview),

Agile Software Development. Agile software development refers to a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self‐organizing cross‐functional teams.

Related concepts

• Acceptance criteria. Specification for a set of conditions that the market exchangeable must meet in order to satisfy the customer. In Agile methodology, the product owner writes statements from the customer’s point of view that explain how a user story or feature should work. In order for the story or feature to be accepted it needs to pass the acceptance criteria; otherwise, it fails.
• Acceptance test. The derivative from the acceptance criteria that verifies whether a feature is functional. The test has only two results: pass or fail. Acceptance criteria usually include one or more acceptance tests.
• Agile methodology. The project management approach of developing increments of software in frequent iterations based on evolving requirements. The Agile Manifesto was the initial public declaration for Agile methodology related to software. Its authors believed that they found "better ways of developing software by doing it and helping others do it."
• Architect. There is no architect role in Agile methodology, instead all team members are responsible for emerging the architecture.
• Backlog grooming. The process that occurs at the end of a sprint, when the team meets to make sure the backlog is ready for the next sprint. The team may remove user stories that aren’t relevant, create new stories, reassess priority, or split user stories into smaller tasks. Backlog grooming is both an ongoing process and the name for the meeting where this action occurs (a backlog grooming meeting).
• Backlog. A changing list of product requirements based on the customer’s needs. The backlog is not a to-do list; rather, it is a list of all the desired features for the product. The Agile team uses the backlog to prioritize features and understand which features to implement first.
• Big visible chart. A large chart displayed near the Agile team that show how the team is progressing. You could make a big visible chart to show defects, velocity (burndown chart), customer acceptance tests, or to find out how much time the team is wasting.
• Burndown chart (or Burndown chart. The chart that represents all outstanding work. The vertical axis represents the backlog, while the horizontal axis represents time. The work remaining can be represented by story points, ideal days, team days, or other metrics.
• Burnup chart (or Burnup chart. The chart that tracks how much work has been completed. There are two lines on the chart—one line represents total work and the other represents work completed. The vertical axis represents the amount of work and can be measured in number of tasks, hours, or story points. The horizontal axis represents time, usually measured in days.
• Capacity. The amount of work that can be completed within a certain time frame and is based on the number of hours that an individual or team will be available to complete the work.
• Continuous improvement. A process of improving quality and efficiency by making small, incremental changes over time. In Kanban, continuous improvement refers specifically to the process of optimizing workflow and reducing cycle time, resulting in increased productivity.
• Continuous integration (CI). A software engineering practice that involves continual integration of new development code into the existing codebase.
• Cycle. refers to the total amount of time it takes for a single task or work item to travel through the workflow from the beginning of work until it ships.
• Daily standup. A brief communication and status-check session facilitated by the Scrum Master where Scrum teams share progress, report impediments, and make commitments for the current iteration or sprint. The Daily Scrum consists of a tightly focused conversation kept to a strict timeframe; the meeting is held at the same time, every day (ideally, in the morning), and in the same location. The Scrum task board serves as the focal point of the meeting. During the Daily scrum each team member answers three questions: (1) "What have I done since the last Scrum meeting? (i.e. yesterday)" (2) "What will I do before the next Scrum meeting? (i.e. today)" (3) "What prevents me from performing my work as efficiently as possible?"
• Done done. A product increment that is considered potentially releasable; it means that all design, coding, testing and documentation have been completed and the increment is fully integrated into the system.
• Emergence. The principle that the best designs, and the best ways of working come about over time through doing the work, rather than being defined in advance, cf. empiricism, self organization.
• Empiricism. The principle of "inspect and adapt" which allows teams or individuals to try something out and learn from the experience by conscious reflection and change, cf. emergence, self organization.
• Epic story. A large user story that, in its current state, would be difficult to estimate or to complete in a single iteration. Epic stories are typically lower priority and are waiting be broken down into smaller components.
• Estimation. The process of assigning a quantifiable measure to the amount of workload needed to complete a project or task, in order to determine the duration, effort, or cost required to complete the project or task.
• Fail-fast. The process of starting work on a task or project, obtaining immediate feedback, and then determining whether to continue working on that task or take a different approach—that is, adapt. If a project is not working, it is best to determine that early on in the process rather than waiting until too much money and time has invested.
• Feature creep. The tendency to add additional requirements or features to a project after development is already underway. Feature creep can occur on either a project or sprint level.
• Fibonacci sequence. Originally derived in the 12th century by Leonardo Pisano, the Fibonacci Sequence is a mathematical sequence in which each subsequent number is determined by the sum of the two previous numbers, that is: 1, 2, 3, 5, 8, 13, 21… Each interval becomes larger as the numbers increase. The sequence is often used for Story Points, simply because estimates are always less accurate when dealing with epic stories.
• The How. A term used to describe the domain of the team, as distinct for the product owner, cf The What. The How can also be described as tactic (i.e. how to win the battle).
• Impediment backlog. A visible or nonvisible list of impediments in a priority order according to how seriously they are blocking the team from productivity.
• Impediment. Any obstacle that prevents an individual or team from completing a task or project. Unscheduled meetings, technical issues, lack of knowledge or expertise, a distracting workplace, and office conflict are all examples of impediments.
• Iteration. A fixed or timeboxed period of time, generally spanning two to four weeks, during which an Agile team develops a deliverable, potentially shippable product. A typical Agile project consists of a series of iterations, along with a Sprint planning meeting prior to development and a Sprint retrospective at the end of the iteration. Iterations are referred to as sprints in Scrum.
• Iterative development. The process of breaking down projects into more manageable components known as iterations. Iterations are essential in Agile methodologies for producing a potentially shippable deliverable or product.
• Kanban. A highly visual framework that falls under the Agile umbrella. The Kanban process uses continuous work flow rather than fixed iterations to produce shippable deliverables. When applied over an existing process, Kanban encourages small, incremental changes to the current process and does not require a specific set up or procedure. Kanban focuses on completing entire projects rather than sprints.
• Lean software development (LSD). An example of lightweight Agile methodology applied to project development. Lean Software Development combines the Lean manufacturing approach pioneered by Toyota in the 1950s (also known as just-in-time production) and Lean IT principles, and applies them to software. LSD places a strong emphasis on people and effective communication. LSD is defined by seven principles: (1) Eliminate waste, (2) Create knowledge, (3) Build quality in, (4) Defer commitment, (5) Optimize the whole, (6) Deliver fast, (7) Respect people
• Pair programming. A scenario where two programmers share a single workstation and work together to develop a single feature.
• Planning poker. A team building exercise or game used to arrive at a group consensus for estimating workload based on the Delphi method.
• Process. simply the way someone works. Everyone has a process. It can be pre-defined, empiric or merely chaotic.
• Product backlog. The list of requirements requested by the customer. The product backlog is not a to-do list; rather, it is a list of all the features the customer has requested be included in the project. The requirements include both functional and non-functional customer requirements, as well as technical team-generated requirements. While there are multiple inputs to the product backlog, it is the sole responsibility of the product owner to prioritize the product backlog. During a Sprint planning meeting, backlog items are moved from the product backlog into a sprint, based on the product owner's priorities.
• Product backlog item (PBI). A single element of work that exists in the product backlog. PBIs can include user stories, epics, specifications, bugs, or change requirements. The product owner of an Agile team compiles and prioritizes the product backlog, putting the most urgent or important PBIs at the top. PBIs comprise tasks that need to be completed during a Scrum sprint—a PBI must be a small enough increment of work to be completed during a single sprint. As PBIs move up to a higher priority in the product backlog, they are broken down into user stories.
• Product owner. A person who holds the vision for the product and is responsible for maintaining, prioritizing and updating the product backlog. In Agile methodology, the product owner has final authority representing the customer's interest in backlog prioritization and requirements questions. This person must be available to the team at any time, but especially during the Sprint planning meeting and the Sprint review meeting. Challenges of being a product owner: (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. (4) Balancing the interests of competing stakeholders.
• Relative estimation. One of several types of estimations Agile teams use to determine the amount of effort needed to complete project tasks. Tasks or user stories are compared against equivalent, previously completed tasks or group of tasks of similar difficulty.
• Release plan. The plan that outlines the features to be included in an upcoming release and provides an estimated date for the release. The plan should include responsibilities, resources, and activities required to complete the release.
• Release. The transition of an increment of potentially shippable product or deliverable from the development team into routine use by customers. Releases typically happen when one or more sprints has resulted in the product having enough value to outweigh the cost to deploy it. A release can be either the initial build of a market exchangeable or the addition of one or more features to an existing market exchangeable. A release should take less than a year to complete, and in some cases, may only take three months.
• Sprint retrospective. A session where the Team and Scrum Master reflect on the process and make commitments to improve.
• Scrum master. 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: (1) Remove the barriers between the development and the product owner so that the product owner directly drives development. (2) Teach the product owner how to maximize return on investment (ROI), and meet his/her objectives through Scrum. (3) Improve the lives of the development team by facilitating creativity and empowerment. (4) Improve the productivity of the development team in any way possible. (5) Improve the engineering practices and tools so that each increment of functionality is potentially shippable. (6) Keep information about the team's progress up to date and visible to all parties. Scrum master is often viewed as the coach for the team.
• Scrum meeting. One of the following: story time, Sprint planning meeting, Sprint review meeting, Sprint retrospective, daily standup.
• Scrum of scrums. A meeting that is a scaling mechanism used to manage large projects involving Scrum multiple teams. A Scrum of Scrums is held to facilitate communication between teams that may have dependencies on one another. One member from each team attends the Scrum of Scrums to speak for the team—this could be the Scrum Master but may be any team member who can effectively relay information and handle questions or concerns for the team.
• Scrum role. One of the following: product owner, Scrum master, team member.
• Scrum. The most widely used framework under the Agile umbrella. Scrum is an iterative software model that follows a set of predefined roles, responsibilities, and meetings. In Scrum, iterations are called sprints and are assigned a fixed length—sprints typically last one to two weeks, but can last as long a month.
• Self organization. The principle that those closest to the work best know how to do the work, so set clear goals and boundaries and let them make all tactical and implementation decisions, cf. emergence, empiricism.
• Spike. A short, time-boxed piece of research, usually technical, on a single story that is intended to provide just enough information that the team can estimate the size of the story
• Sprint backlog. A segment of Product Backlog Items (PBIs) that the team selects to complete during a Scrum sprint. These PBIs are typically user stories taken from the product backlog.
• Sprint goal (aka Sprint theme). The key focus of the work for a single sprint.
• Sprint plan. The tangible outcome of a Sprint planning meeting. The Sprint plan is a written document assembled by the development team and includes 1) the goal for the sprint—a brief description of the product or deliverable to be completed by the end of the sprint, and 2) a detailed list of the Product Backlog Items (PBIs) or user stories the team has committed to completing by the end of the sprint, based on the team’s availability and velocity. Each PBI or user story is broken down into tasks according to the priority set by the product owner and assigned to a team member.
• Sprint planning meeting. A working session held before the start of each sprint to reach a mutual consensus between the product owner's acceptance criteria and the amount of work the development team can realistically accomplish by the end of the sprint. The length of the sprint determines the length of the Sprint planning meeting, with two hours being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last about four hours, although this can vary.
• Sprint retrospective. A meeting held following the completion of a sprint to discuss whether the sprint was successful and to identify improvements to be incorporated into the next sprint.
• Sprint review meeting. A meeting that a Scrum team holds immediately following the completion of a sprint to review and demonstrate what the team has accomplished during the sprint. This meeting is attended by the product owner or customer, Scrum Master, Scrum team, and stakeholders. The Sprint review meeting is an informal meeting (no Powerpoint slides allowed). The length of the sprint determines the length of the Sprint review meeting, with one hour being equivalent to one week of the sprint. Using this formula, the Sprint planning meeting for a two-week sprint would last two hours, although this can vary.
• Sprint task. A single small item of work that helps one particular story reach completion.
• Sprint. A fixed-length iteration during which one user story or product backlog item (PBI) is transformed into a potentially shippable deliverable. Each sprint is assigned a set amount of time to be accomplished (sometimes referred to as Timeboxing), which could be anywhere from one week to one month, but typically lasts two weeks.
• Stakeholder. Anyone outside the Scrum team who has an interest in the product that the team is producing. Stakeholders can include but are not limited to direct managers, subject matter experts, account managers, salespeople, and legal officers.
• Story mapping. refers to a top-down visualization, or roadmap, of product backlog. The story map starts with a goal or specific functionality, which is then broken down into user stories. A story map is created in tree format either physically, using post-its on a wall, or digitally.
• Story point. A non-unit measure used to determine the complexity of a user story. Story points are relative, not absolute, and do not relate to actual hours—they can be anything from tee-shirt sizes to the Fibonacci Sequence.
• Story time. A regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
• User story. A brief, non-technical statement of a software system requirement written from the end-user's point of view. A story is written according to the following structure: as a [type of user], I want to [perform some task (or execute a function)] so I can [achieve some goal (or get some value)].
• Sustainable pace. The pace that an Agile team can work at indefinitely without resulting in developer burnout (ideally 40 hours per week).
• Swarming. Mutual work of team members with appropriate skills work together to complete a task that a team member is having trouble completing on his or her own.
• Task board. A physical or online visual representation of user stories broken down into tasks or work units. A physical task board can be as simple as a whiteboard with three columns labeled To Do, Doing, and Done; colored post-it notes or index cards representing tasks are placed in the column that reflects the task's current state. A task board can be expanded to hold more columns and can also include horizontal swim lanes.
• Task list. A list of tasks needed to complete the set of stories committed to a sprint.
• Task. A single unit of work broken down from a user story. A task is usually completed by just one person.
• Agile team member. A member of an Agile team. Often, Agile team include engineers, architects, developers, analysts, QA experts, testers, UX designers, etc.
• Agile team. A workteam that is responsible for committing to work, delivering and driving the product forward from a tactical perspective in terms of Agile methodology. Usually, an Agile team is a small, high-functioning group of five to nine people who collaboratively work together to complete an iteration or project. The team has the necessary skills and competencies to work on the project. Scrum teams are cross-functional; Kanban teams can either be cross-functional or specialists. Scrum teams lack any roles. Kanban teams usually have team leads.
• Technical debt. refers to the obligation a development team incurs when they use a short-term, expedient approach to developing a software package without considering the long-term consequences. Technical debt increases project cost and complexity due to inefficiencies, inaccuracies, and other issues introduced into the software package. Poor management, incompetency, timeline pressure, or inadvertent mistakes can all contribute to technical debt.
• Test-driven development (TDD). The practice of designing and building tests for functional, working code, and then building code that will pass those tests.
• Thumb vote. A quick pulse to get a sense of where the team are in terms of commitment, or agreement on a decision, etc. thumb up generally means agree, yes, or good, and thumb down disagree, no or bad; the analog version of this allows the thumb to be anywhere on the half circle to indicate differing degrees of agreeability.
• Timebox. An assigned period of time during which an individual or team works toward an established goal. The team stops work when the time period concludes, rather than when work is completed. The team then assesses how much work was accomplished toward the specified goal.
• Timeboxing. Setting a duration for every activity and having it last exactly that (i.e. neither meetings nor sprint are ever lengthened - ever).
• Unit testing. A short program fragment written for testing and verifying a piece of code once it is completed. A piece of code either passes or fails the unit test. The unit test (or a group of tests, known as a test suite) is the first level of testing a software development product.
• User persona. A detailed hypothetical description or biography of a typical end-user who will be using the product. Personas usually take the form of a written document, complete with stock photo, name, profession, style of living, and other details pertinent to their being categorized as an end-user.
• User story. A brief, non-technical description of a software system requirement written from the customer’s or end-user’s point of view. Either the product owner or the team writes the user stories according to the following structure: as a <type of user>, I want to <perform some task> so I can <achieve some goal.>
• Velocity. A metric that specifies how much work a team is able to complete within a single, fixed-length iteration or sprint.
• Product vision statement. a high-level description of a product which includes who it is for, why it is necessary and what differentiates it from similar products.
• The What. A term used to describe the domain of the product owner, as distinct for the team, cf. The How. The What can also be described as strategy (i.e. what's the best order for battles).
• Work-in-progress limit (WIP). refers to work that is currently being developed and not yet ready to be released as a deliverable. For Scrum teams, this would apply to the work being accomplished during a sprint. For Kanban teams, this refers to work that has been pulled from the backlog and is being developed, indicated by cards in the ‘Doing’ or ‘Work-in-Progress’ column of the Kanban task board.

Related lectures

• Agile Career Projects.
• Project Management Quarter.