Agile methodology

• Acceptance criteria. Specification for a set of conditions that the product must meet in order to satisfy the customer. In Agile development, 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 development. 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 development 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 development, 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. 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. 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.
• Impediment. anything that prevents the team from meeting their potential (e.g. chairs are uncomfortable). If organizational, it is the Scrum Master's responsibility to eliminate it. If it is internal to the team, then they themselves should do away with it.
• 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 planning meeting prior to development and a retrospective meeting 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 game. refers to a planning meeting held to decide which user stories to include in the next iteration or release.
• 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. As a member of the Agile team, the Product Owner represents the customer, and conveys the customer’s requirements and vision to the team. The product owner writes the acceptance criteria, and prioritizes and maintains the product backlog. Product owners should be able to communicate well in both directions: both taking team concerns to the customer and stakeholders, and ensuring that the team stays on track to meet the customer’s vision for the product.
• Product Owner. person whom holds the vision for the product and is responsible for maintaining, prioritizing and updating the product backlog. In Scrum, 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.
• Refactoring. Refactoring code means to improve, clarify, and streamline the internal structure of existing code without affecting its external behavior. Refactoring does not include rewriting code or fixing bugs. The noun “refactoring” refers to specific, finite methods for refactoring code, such as using Extract Method to clarify the purpose of a piece of code.
• 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.
• Relative Estimation. sizing backlog items by grouping them into relative size ranges rather than by absolute units (e.g. – hours). See Fibonacci and t-shirt sizes.
• Release Burndown Chart. a visible chart to show progress towards a release.
• Release plan. 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. An Agile release refers to the final delivery of a software package after the completion of multiple iterations or sprints. A release can be either the initial build of an application or the addition of one or more features to an existing application. A release should take less than a year to complete, and in some cases, may only take three months.
• Release. The transition of an increment of potentially shippable product 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.
• Retrospective. a session where the Team and Scrum Master reflect on the process and make commitments to improve.
• Scrum Master Role. The ScrumMaster is a facilitator for the team and product owner. Rather than manage the team, the ScrumMaster 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. ensures that participants call sidebar meetings for any discussions that go too far outside these constraints. The Scrum literature recommends that this meeting take place first thing in the morning, as soon as all team members arrive.
• Scrum master. Often viewed as the coach for the team. He or she organizes meetings, resolves roadblocks and issues, and works with the product owner to make sure the product backlog is up to date. The Scrum Master does not have any authority over team members, however, he or she does have authority over the process. A Scrum Master may complete formal training to become a certified Scrum Master but this is not required.
• Scrum Meetings. Story Time, Planning, Review, Retrospective, Daily Scrum
• 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 Roles. there are only three: product owner, Scrum Master, team member
• Scrum team. typically comprises five to nine members with cross-functional skills. Unlike traditional teams of developers, there are no specific roles. A Scrum team is self-organized and self-contained—the team should have the right amount of members with the appropriate skills needed to complete the sprint.
• 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
• Spike. refers to a separate timeboxed user story or task that is created in order to research a question or resolve a problem. A spike focuses on gathering information and providing an answer to a question, rather than producing a shippable product.
• 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 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 Burndown. a visible chart that indicates on a daily basis the amount of work remaining in the sprint.
• 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 planning meeting, with two hours being equivalent to one week of the sprint. Using this formula, the planning meeting for a two-week sprint would last about four hours, although this can vary.
• Sprint Planning. a meeting between the Team and the Product Owner to plan the sprint and arrive at an agreement on the commitment.
• 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. The Scrum team holds a Sprint Review meeting 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 is an informal meeting (no Powerpoint slides allowed). The length of the sprint determines the length of the review meeting, with one hour being equivalent to one week of the sprint. Using this formula, the 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.
• Sprint. a time boxed iteration
• Stakeholder. loosely refers to 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.
• Stakeholder. Sometimes the following terms are used synonymously – although it should be noted that there are nuances in their definitions: story, user story, technical user story, product backlog item, PBI, and product requirement.
• 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 Point. a unit of measurement applied to the size of a story, cf. Fibonacci Sequence T-shirt sizes, powers of 2, are other ways of assigning Story Points.
• Story Time. the regular work session where items on the backlog are discussed, refined and estimated and the backlog is trimmed and prioritized.
• Story (or 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> so I can <achieve some goal.>
• Story. a backlog item usually using the template form: as a [user] I want [function] so that [business value], cf Product Backlog Item.
• Sustainable pace. The pace that an Agile team can work at indefinitely without resulting in developer burnout (ideally 40 hours per week).
• Swarming. When 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. the 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.
• Taskboard. a wall chart with cards and sticky notes that represent all the work of a team in a given sprint; the task notes are moved across the board to show progress.
• Team Member. a team member is defined as anyone working on sprint tasks toward the sprint goal. In Scrum parlance, the PO and SM could also be Team Members, if they are developing.
• Team member. In an Agile, Scrum, or Kanban environment, a 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.
• Team. A team (or "Scrum development team") is optimally comprised of seven plus or minus two people and responsible for committing to work, delivering and driving the product forward from a tactical perspective. For software development projects, the team members are usually a mix of software engineers, architects, programmers, analysts, QA experts, testers, UI designers, etc. This is often called "cross-functional project teams". Agile practices also encourage cross-functional team members. During a sprint, the team self-organizes to meet the sprint goals. The team has autonomy to choose how to best meet the goals, and is held responsible for them. The ScrumMaster acts as a guardian to ensure that the team is insulated from the product owner. Scrum also advocates putting the entire team in one team room.
• 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. refers to 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.
• Velocity. the rate at which a team completes work, usually measured in story points. In Scrum, velocity is how much product backlog effort a team can handle in one sprint. This can be estimated by viewing previous sprints, assuming the team composition and sprint duration are kept constant. It can also be established on a sprint-by-sprint basis, using commitment-based planning. Once established, velocity can be used to plan projects and forecast release and product completion dates. How can velocity computations be meaningful when backlog item estimates are intentionally rough? The law of large numbers tends to average out the roughness of the estimates.
• 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.
• What. the What is a term used to describe the domain of the product owner, as distinct for the team, cf. How. 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.