Agile

Agile Principles

1) Satisfy the customer through delivery of working software. 2) Embrace change, even if introduced late in development. 3) Continue to deliver functioning software incrementally and frequently. 4) Encourage customers and analysts to work together daily. 5) Trust motivated individuals to get the job done. 6) Promote face-to-face conversation. 7) Concentrate on getting software to work. 8) Encourage continuous, regular, and sustainable development. 9) Adopt agility with attention to mindful design. 10) Support self-organizing teams. 11) Provide rapid feedback. 12) Encourage quality. 13) Review and adjust behavior occasionally. 14) Adopt simplicity.

Scrum Artifacts

1. Product Backlog 2. Sprint Backlog 3. Burndown Chart

Pivot

A "structured course correction designed to test a new fundamental hypothesis about the product, strategy, and engine of growth."

Routine

A codification of a "how". Represents a best practice associated with this activity. The ecosystem members commit to maintaining the routines through their various Sprints to ensure they always represent the most current way of doing this activity

Product Backlog

A collection of stories and tasks the Sprint team will work on at some point in the future. Either the Product Owner has not prioritized them or has assigned them lower priority. Teams or organizations may use the term "backlog" in one of the following four ways: 1. Stories or tasks that are likely to be considered in the next iteration's planning game. 2. Stories or tasks that are definitely planned to be worked on in the next iteration (rather than just being available for consideration). 3. Stories or tasks that are assigned to the current iteration, but are not being worked on, yet. As the team has time, these will be worked on after the higher priority items are completed. 4. In a very fluid team, the planning game may assign more stories than can be done during the iteration. The backlog consists of stories and tasks that may slip into the next iteration.

Mind Map

A diagram used to visually outline information. A mind map is often created around a single word or text, placed in the center, to which associated ideas, words and concepts are added. Major categories radiate from a central node, and lesser categories are sub-branches of larger branch.

Parking Lot

A facilitators tool, usually in the form of a white board area or paper stuck on the wall to make note of topics that although not directly relevant to the topic being discussed at the time are important and should be discussed at a point later in time. It is the facilitators responsibility to ensure all parking lot items are followed up on by some pre-determined date.

Scrum

A framework for the iterative development of complex products, particularly software. Comprised of a series of short iterations - called sprints - each of which ends with the delivery of an increment of working software.

Backlog

A listing of product requirements and deliverables to be completed, written as stories, and prioritized by the business to manage and organize the project's work.

Quality Automation Engineer (QAE)

A member of the QA organization. QAEs create automation for a Product Application area.

Quality Assurance Engineer

A member of the QA organization. QAs support Regression activities for a Product Application area. QA team members execute Manual and Automated Test cases. QAs maintain the Regression suite by adding, modifying or deleting test cases for regression suites.

Iteration

A period (from 1 week to 2 months in duration) during which the Agile development team produces an increment of completed software. All system lifecycle phases (requirements, design, code, and test) must be completed during the iteration and then demonstrated for the iteration to be accepted as successfully completed. At the beginning of the iteration, the business or the product owner identifies the next (highest priority) chunk of work for the team to complete. The development team then estimates the level of effort and commits to completing a segment of work during the iteration. During the iteration, the team is not expected to change objectives or respond to change requests. However, at the front end of the next iteration the business or product owner is free to identify any new segment of work as the current highest priority. Also called a Sprint in Scrum.

Stakeholder

A person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review.

Increment

A piece of working software that adds to previously created Increments, where the sum of all Increments - as a whole -- form a product.

Release Plan

A plan that forecasts, for up to 3 months, the delivery of functionality described in the backlog by the team. This plan should be updated regularly and considered as a rolling plan. As the team learn more about their capabilities, the system they are working on and as priorities and requirements change so should the plan.

Sprint Zero

A preliminary sprint, exclusively dedicated to preparing for the first sprint. Sprint Zero can focus in on the team's physical environment, or use it as an opportunity to prepare the team for its first sprint planning meeting.

Minimum Viable Product

A product with just enough features to satisfy early customers, and to provide feedback for future product development.

Non-Functional Requirement (NFR)

A requirement that specifies criteria that can be used to judge the operation of a system, rather than specific behaviors. Often called qualities of a system.

Release Train

A scaling model for enterprise Agile programs that synchronizes the vision, planning, interdependencies, and delivery of many teams on a cadence.

Fibonacci Sequence

A sequence of numbers in which the next number is derived by adding together the previous two (e.g. 1, 2, 3, 5, 8, 13, 21, 34...). The sequence is frequently used to size stories in Agile estimation techniques. Scrum teams typically modify the higher numbers in the sequence to avoid the appearance of percision (e.g. 1,. 2, 3, 5, 8, 13, 20, 50, 100 ...)

Engineering Standards

A shared set of development and technology standards that a Development Team applies to create releasable increments of software.

Definition of Done

A shared understanding of expectations that software must live up to in order to be potentially releasable. Managed by the Development Team. Every team will have their own Definition of Done with teams working on the same product using a common minimum definition.

Minimal Marketable Feature (MMF)

A small, self-contained feature that can be developed quickly and delivers significant value to the user

Continuous Delivery (CD)

A software development discipline where you build software in such a way that the software can be released to production at any time. 1. You can deploy software at any point in its lifecycle 2. In the event that the software is for whatever reason not deployable, the Delivery Team swarms to rectify the issue. 3. Anyone can get fast, automated feedback on the production readiness of their systems if and when anyone makes a change

Spike

A special type of User Story that allows for Business or Technical discovery to better understand some unknown. Spike's must be time-boxed to a small number of days to ensure that only an appropriate amount of time is spent on discovery. Results of the spike are typically refined User Stories.

MoSCoW

A technique used to categorize the importance of different attributes in a product from Customer point of view to enable the development team to place importance on the delivery of each requirement. This teaching is useful in defining the 'Acceptance Criteria' of a product or release by specifying 'Must Have, Should Have, Could Have, and Won't Have' requirements.

Steel Thread

A term used to describe some minimal thread of functionality through a product. It is being able to do something simple to and input so that something basic happens on an output. It is small relative to what remains but significant in that you know the design is doing something right.

Retrospective

A timeboxed meeting held at the end of an sprint, iteration, or at the end of a release, in which the team examines its processes to determine what succeeded and what could be improved. The retrospective is key to an Agile team's ability to "inspect and adapt" in the pursuit of "continuous improvement."

Sprint Review

AKA Demo. Occurs at the end of every Sprint. It serves for the Scrum Team and the stakeholders to informally inspect the Increment of product resulting from the Sprint, assess the impact of the work performed on overall progress toward their next functional milestone and update the Product backlog in order to maximize the value of work created in the following Sprints.

Acceptance Criteria

Acceptance Criteria is the portion of a user story that indicates what the customer or user expects to see in the new or updated functionality. The functionality will be tested against these criteria. It is sometimes written using the Give-When-Then (Gherkin/Cucumber) method: Given <some pre-condition>, when <trigger occurs>, then <creates expected results>.

Agile

Agile is a set of values and principles around developing software in a more iterative, collaborative and adaptive way. Agile can also be thought of as a mindset that uses learning and discovery to remove uncertainty in the product development process. There are various frameworks and methodologies that implement Agile values and principals such as Scrum & XP.

Pair Programming

An XP technique in which two programmers / developers work together at one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of the code as it is typed. The two programmers switch roles frequently.

Point-Based Estimation

An estimation technique to estimate story sizes relative to each other, and then use past experience to determine how much can be done in an iteration. To determine the points for a story, we compare rough relative sizes. If we are estimating a story, we look for a story of similar size that we've already estimated and determine the relative points for the new story.

Sprint

An iteration of software development within the Scrum framework, typically between 1-4 weeks, in which a Scrum team develops in entirety a small subset of work based on highest business value in the product backlog - a potentially shippable product Increment.

Roadmap

An overall view of the product's requirements and a valuable tool for planning and organizing the journey of product development. The product owner creates the product roadmap with help from the development team. The roadmap is used to categorize requirements, to prioritize them, and to determine a timetable for their release.

Sprint Backlog

An overview of the development work to realize a Sprint's goal, typically a forecast of functionality (stories) and the work needed to deliver that functionality (tasks). Created by the Development Team during Sprint Planning and managed them durimg the course of the sprint.

Code Smell

Any symptom in the source code of a computer program that indicates something may by wrong

Product Backlog Item (PBI)

Any work related to changing the product (story, defect, etc.).

Impediment

Anything stopping the team from operating at peak efficiency. Impediments should be reported to the Scrum Master as soon as possible. It is the Scrum Masters responsibility to either remove or escalate the impediment.

Sprint Planning

As a general rule of thumb, the number of weeks in a sprint multiplied by two hours equals the total length of the spring planning meeting. Part one of the sprint planning meeting is a review of the product backlog. This is when the product owner describes what needs to be built for the next sprint. During this part of the meeting, it is not uncommon for the team to discuss the sprint objectives with the product owner, and ask clarifying questions and remove ambiguity. During part two of the sprint planning meeting, the team decides how the work will be built. The team will begin decomposing the product backlog items into work tasks and estimating these in hours. The output of the second planning meeting is the Sprint Backlog.

Refactoring

Changing existing software code in order to improve the overall design. Refactoring normally doesn't change the observable behavior of the software; it improves its internal structure. For example, if a programmer wants to add new functionality to a program, she may decide to refactor the program first to simplify the addition of new functionality in order to reduce technical debt. Refactoring is one of the original twelve extreme programming practices and is considered critical for incrementally maintaining technical quality on Agile projects. Refactoring is made practical through engineering discipline of good Unit Tests.

Flow

Continuous delivery of value to customers vs. big-batch, big-release, big-bang.

Scrum Ceremonies

Daily Scrum Sprint Planning Sprint Review Sprint Retrospective Backlog Grooming Story Estimation

Relative Estimate

Estimating in relative terms rather than absolute terms. Instead of saying, "This will take five days," say, "This thing will take about as long as that thing."

Release

In this ecosystem, an SAE release represents a portfolio-wide deployment of application features and functionality at the same time to production. This "Release" concept implies this feature/functionality is coordinated across all projects/initiatives.

Agile Manifesto

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

Kaizen

Japanese for "improvement" or "change for the best", refers to philosophy or practices that focus upon continuous improvement of processes. By improving standardized activities and processes, kaizen aims to eliminate waste.

Kanban

Kanban is a tool derived from lean manufacturing and is associated with the branch of agile practices loosely referred to as Lean software development. Like a task board, Kanban visually represents the state of work in process. Unlike a task board, the Kanban constrains how much work in process is permitted to occur at the same time. The purpose of limiting work in process is to reduce bottlenecks and increase throughput by optimizing that segment of the value stream that is the subject of the Kanban. Task boards simply illustrate work in process without necessarily deliberately how much of work in process may occur at any given time, although the same effect may be achieved through the organic self-organization of the team. A principle difference between Kanban and Scrum is that Scrum limits work in process through timeboxing (i.e. the sprint) and Kanban limits work in process by limiting how much work may occur at one time (e.g. N tasks or N stories) but with continuous flow.

Lean Thinking

Lean Thinking gives teams tools to see excessive waste, ceremony and complexity within our processes, recognizing the impediments worth removing and applying improvement to obtain the desired result. Waste in software development can take many forms but is most often associated with wait time created by hand-offs between groups.

Daily Standup

One such meeting that ideally occurs on a daily basis.

Experiment

Performed by a team to improve their performance - the team decides how long they want to run the experiment and what constitutes Success and Failure.

Release Planning

Planning activities used to estimate when software will be released into production. Activities include projecting the level of effort in terms of the number of iterations that will be necessary to deliver the desired features.

Grooming

Product Backlog Refinement

Scrum Roles

Product Owner Scrum Master Development Team

Product Owner (PO)

Product Owner is one of the key roles in Scrum. The product owner is the primary business representative who represents the business stakeholders' "voice of the customer" and the "voice of the business" to the sprint team. The responsibilities of the Product Owner include: 1. Establishing, nurturing, and communicating the product vision 2. Creating and leading a team of developers to best provide value to the customer 3. Monitoring the project against its ROI goals and an investment vision 4. Making decisions about when to create an official release The product owner is a role rather than a position. Consequently, several people likely participate in the product owner role for larger projects.

Quality Assurance (QA)

Quality Assurance Department

Colocation

Refers to when a Development Team is located and working in the same location

Just In Time (JIT)

Requirements aren't analyzed or defined until they are needed. Only a small initial investment is required at the start. Development is allowed to begin with incomplete requirements. Analysis and requirements definition is continuous throughout the project. Requirements are continuously refined as the project moves forward. Change is expected and easy to incorporate into requirements.

Scrum Master (SM)

Responsible for maintaining the Scrum process and the overall health of the team. Assures that the team is fully functional and productive. Performs this role by administering the Scrum activities, facilitating self-organization of the team, and removing any obstacles that may be impeding the team's progress.

"Chicken"

Scrum slang for someone who is interested in a project but has no responsibility for working on a task in the active iteration. They may observe team meetings but cannot vote or talk.

Scrum-ban

Scrum-ban is especially suited for maintenance projects or (system) projects with frequent and unexpected work items or programming errors. In such cases the time-limited sprints of the Scrum model are of no appreciable use, but Scrum's daily meetings and other practices can be applied, depending on the team and the situation at hand. Visualization of the work stages and limitations for simultaneous unfinished work and defects are familiar from the Kanban model. Using these methods, the team's workflow is directed in a way that allows for minimum completion time for each work item or programming error, and on the other hand ensures each team member is constantly employed.

"Pig"

Someone who is responsible for doing a task on an active iteration. It comes from the joke, "A chicken and a pig talk about breakfast. The chicken says, 'Let's have bacon and eggs.' The pig replies, 'That's fine for you. You are just making a contribution, but I have to be fully committed.'" Pigs are actively involved in the project.

Product Backlog Refinement

The activity in a Sprint through which the Product Owner and the Development Team add granularity to the Product Backlog to prepare future work so that it is ready for the team.

Regression Testing

The intent of regression testing is to ensure that a change has not introduced new faults, and to determine whether a change in one part of the software affects other parts of the software.

Self Organization

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.

Emergence

The process of the coming into existence or prominence of new facts or new knowledge of a fact, or knowledge of a fact becoming visible unexpectedly. The best designs, and the best ways of working come about over time through doing the work, rather than being defined in advance.

Customer

The recipient of the output (product, service, information) of a process. May be internal or external to the organization. May be one person, a department, a large group or internal stakeholders (outside of Information Technology) are sometimes called the "Business."

Development Team

The role within a Scrum Team accountable for managing, organizing and doing all development work required to create a releasable Increment of product every Sprint. Consists of the people with the skills required to create the product Increment each Sprint.

Potentially Shippable Increment (PSI)

This is an artifact (usually a software build) that is delivered to the business, via a demo as a deliverable element. An example would be a build to the Stakeholder team external to the team. This is delivered via Sprint Review venue.

Build Increment

This is an artifact (usually a software build) that is delivered to the client as a deliverable element. An example would be a build to the client outside of the Agile team. This is delivered via Sprint Review venue. In Scrum, the build increment is simply called the Increment.

Point

Used for sizing stories in agile projects. They provide a technique to aid planning by providing a forecast of when stories can be completed.

Splitting a Story

User Stories that are too big to be expected to achieve the team's Definition of Done in one Sprint should be split into two or more User Stories. This is part of Product Backlog Refinement. Typically, the most effective way to split a User Story is along Test Case boundaries from the Acceptance Criteria.

Push

a task is created and then assigned to an owner. A task could be anything from the implementation of a requirement (or a component needed to realize a requirement) to a bug fix to a document to write. Someone, usually some kind of manager or team leader, takes the units of work that need to be done and then allocate them to the members of the team to complete. Simply, work is pushed onto the people who will be doing it.

Lean-Agile

combination of Lean Thinking and Agile disciplines. Lean is the "What" and Agile is the "How"

Cross Functional Team

composed of various members with different areas of functional expertise

Cycle Time

continuous flow process like Kanban is the measure of how long it takes an item to be completed (the time it takes for a story to be done).

Application Lifecycle Management (ALM)

continuous process of managing the life of an application through governance, development and maintenance.

Cumulative Flow (CFD)

diagram provides a graphic depiction of how stories are moving through various statuses on the way to being "Done".

Persona

first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of person who would interact with it.

Burndown Chart

graphical representation of the amount of work to be completed (Y-Axis) based on a specific time interval (X-Axis). The burndown chart can be used on a project level or sprint level.

Feature Set

is a collection of Features that, together, performs some value to the business.

Planning Poker

is a consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development.

Feature

is a high grained collection of functionality that provides recognizable and immediate benefit to the end consumer. Typically named (titled) with a "verb noun" construct such as "Customer Management". Features can be rolled up into Feature Sets and Features are realized by User Stories. Features contain User Stories. Features are the cross-functional "vertical slice" (steel-thread) that binds together one to many application teams to each deliver a User Story or collection of these to complete the functionality.

Lean Coffee

is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated.

Feature Group

is a theme or a functional categorization of stories, rather than a specific capability. The grouping of stories can be pulled from disparate epics or sections of the backlog. An example of a feature group is reporting. The stories associated to reporting could come from the account management and subscription epics.

Epic

is any Backlog Item that is too large to completed in a single sprint and therefore must be broken down into smaller User Stories.

Forecast

is the selection of items from the Product Backlog a Development Team deems feasible for implementation in a Sprint.

Definition of Ready

it provides a shared understanding by the Product Owner and the Development Team regarding the preferred level of description of Product Backlog items introduced at Sprint Planning.

Estimation

may only be done by the Development Team doing the work.

Distributed Team

members are geographically dispersed. Teams may encounter challenges with time zone differences, lack of face-to-face communication, etc.

Build Process

refers to source code integration. A software developer will generate code in an integrated environment. Before a release, the code is converted to a stand-alone format that is executable. It's critical for the code to be integrated and run together in an automated process.

Continous Integration

software development practice that requires team members to integrate their code frequently to avoid integration challenges

Block

status indicator which signals to the team that there is an issue with a story/epic.

Automated Testing

the process of executing pre-scripted test cases before the code hits production. A major benefit of using automation is that tests can be run repeatedly, any time of the day.

Pull

the tasks that must be done are stored in a queue, often a priority queue of sorts. An example is the product backlog, which contain user stories that are to be done. A developer who is currently not working on anything will go to the queue and take off the highest priority story that they are able to do and work on it. The people who are doing the work pull the work out of a list and do it.

Hardening Sprint

the team stops focusing on delivering new features or architecture, and instead spends their time on stabilizing the system and getting it ready to be released. For some people, hardening sprints are for completing testing and fixing work that couldn't be done - or didn't get done - earlier. This might include UAT or other final acceptance testing if this is built into a contract or governance model.

Empiricism

three pillars: transparency, inspection and adaptation. This approach allows teams to try something out and learn from the experience by conscious reflection.

Burnup Chart

tracks completed work and total work (Scope) with two separate lines, unlike a burndown chart which combines them into a single line. The total work line communicates important information -- is the project not yet complete because work is slow to be done, or too much new work is being added. This information can be crucial in diagnosing and rectifying problems with a project.

Capacity

used to determine how much work can be accomplished in a sprint.. three factors for each team member, for each sprint: Number of ideal hours in the work day Days in the sprint that the person will be available Percentage of time the person will dedicate to this team

Given-When-Then (GWT)

writing behavior oriented acceptance tests in user stories. 1. The purpose of Given is to put the system in a known state before the user (or external system) starts interacting with the system 2. The purpose of When steps is to describe the key action the user performs 3. The purpose of Then steps is to observe outcomes. The observations should be related to the business value/benefit in your feature description. The observations should also be on some kind of output - that is something that comes out of the system