Chapter 6. Real Terms, Real Definitions
One of the most popular requests I receive is for terms and definitions. In addition to providing a comprehensive list for the articles and other portions of this book, I have included this glossary of sorts to serve as a reference for the reader.
This is not an all-inclusive list, but rather a collection of the most commonly used terms in Agile based on my experience.
When we attempt to guess at the cost or time for a particular task or feature, we are engaging in absolute estimating; that is, we are looking at individual items and assigning some value to them based upon an absolute scale. This is in contrast to relative estimating.
Acceptance Criteria
Short statements of conditions that must be met in order for the product owner to consider the feature to be “done.” For instance: I know this feature will be done when I can enter a vehicle price of $15,999.00 for Hawaii and I get a final price of $22,761 with all appropriate federal, state, and local taxes applied. A feature is incomplete without acceptance criteria.
Acceptance Test Driven Development (ATDD)
An approach to ensuring technical excellence and customer delight by using the acceptance criteria written by the product owner to drive the creation of automated unit tests and then using these unit tests as the basis of doing test-driven development (TDD). There are tools in the marketplace that will parse plain-text acceptance criteria and automatically turn these into tests for TDD so that no technical expertise is required by the product owner.
Affinity Estimating
A method of estimating a large number of items relatively quickly without in-depth discussions about each item. Works best when the items are already fairly well understood; that is, have already been discussed, have acceptance criteria, etc. The team posts the items on a wall from smallest to largest and then groups them together under the headings for the estimation unit. Little or no discussion happens. The team simply moves the items along the wall.
Affinity Grouping
A method of categorizing a group of items by themes or similar concepts. Items with a higher degree of correlation are closer together; those that are more disparate are further away from each other. Good for discussion topics.
Agile
A set of values and principles that embrace change, collaboration, customer delight, and continuous innovation in the pursuit of profitability.
Anything that is created by a human. A product is an artifact, as are the code, product increment, test scripts, test cases, unit tests, user manuals, deployment scripts, SOX controls, burndown charts, backlogs, etc. Scrum only prescribes several artifacts: sprint and release burndown charts, product backlog, sprint backlog, and the shippable product increment.
Avogadro’s Number
The number of constituent particles that comprise a mole of a particular substance; used in chemistry and physics. The number is given to be 6.022 × 1023. This has nothing to do with Agile or Scrum. I just happen to like science.
Backlog
A backlog is simply an ordered list of items that are intended to be worked on with the highest value or most important items at the top and the least valuable or least important items at the bottom. It is ordered so that it is clear what comes first, what is immediately next, what is immediately next, and so on. This is in contrast to priority where there are categories of priority and multiple items being assigned these categories; for example, High, Medium, Low.
Backlog Refinement
An ongoing activity in which the product owner adds, removes, moves, or splits items into smaller items. They also add acceptance criteria to the items so that the development team has a clear expectation of when the items will be considered “done” and so that they can provide an estimate of the effort and complexity of the item.
Business Sponsor
Refers to the primary person responsible for the funding of a product in organizations that leave this responsibility to a single person, that is, “the person who signs the checks.” In smaller organizations, the product owner might be the business sponsor. However, in many organizations, the business sponsor is someone in senior or executive management and would not be “hands-on” enough to create product backlog items or be available on a daily basis for the development team.
Certified Enterprise Coach (CEC)
The CEC certification is a highly sophisticated and prestigious designation at the top level within the Scrum Alliance. A candidate must demonstrate that they are coaching across entire organizations and enterprises using concepts and disciplines that go well beyond the basic Scrum practices. A skilled Enterprise Coach will be thinking in terms of systems within an organization: how all the parts integrate and work together to in turn form larger systems at the macro level, while these parts are themselves systems at the micro level. There are concepts of organizational development psychology and sociology, which the coach regularly draws upon in their coaching approach. The CEC has a mind toward organizational culture and how various factors influence and define the culture—how the culture needs to support the practices of Scrum. CEC candidates are peer reviewed, and the community is very collegial and respectful to its members.
Certified Scrum Product Owner (CSPO)
An entry-level certification for product owners created and maintained by the Scrum Alliance. The scope of practice for a CSPO is acting as a product owner for a single product delivered by a single development team as part of a single Scrum Team. It is not expected that a CSPO will be able to be the CSPO for multiple products, products that require multiple teams to deliver, or other configurations within an organization commonly referred to as scaling. These are advanced topics and concepts, which require coaching and mentoring by an experienced Scrum Coach. When a CSPO eventually establishes this level of expertise, they can apply for the Certified Scrum Practitioner certification, which indicates that the certificant has experience, not just classroom training.
Certified Scrum Professional (CSP)
A Certified Scrum Professional has successfully completed one or more of the baseline certifications (CSM, CSPO, CSD) and has significant experience practicing Scrum. They also have additional education beyond the entry-level class, as evidenced by the SEU requirement of the certification. CSPs are expected to be able to coach multiple ScrumMasters, product owners, and development teams. A CSP could reasonably coach and facilitate a multiteam effort and lead an Agile transformation for a business unit or department of a larger organization.
Trainers are licensed to teach CSM and CSPO courses. They have demonstrated extensive knowledge and command of all various flavors of Scrum and concepts that support Scrum. They have also demonstrated their ability to construct classroom training that is engaging and supports the concepts of Agile/Scrum. The certification process is peer reviewed; the Trainer Acceptance Committee is composed of fellow CSTs. The candidate is required to submit their materials for the class, recommendations, and other proof of training abilities. If they are able to successfully demonstrate competence on the application, they are invited to interview, where they will be asked questions in person and be required to provide a live sample of their training.
Certified ScrumMaster (CSM)
An entry-level certification for ScrumMasters created and maintained by the Scrum Alliance. The scope of practice for CSMs involves the coaching, mentoring, and facilitation for a single team; that is, it is not expected that a CSM will be able to lead organization-wide Agile transformation initiatives, which involve topics such as scaling, distributed teams, portfolio management, etc. A CSM should be focused on helping the Scrum Team they serve become a high-performing team.
Change Management
The process or mechanism by which changes are made to requirements used for product development. In defined process control, the change management process is very formal and structured with extensive documentation and official sign-offs, etc. This approach is often very time consuming. In empirical process control, the change management process is much more lightweight and amenable to small, rapid changes based upon frequent inspection and adaption. Also, in Scrum, change management takes place in large part through the backlog refinement efforts of the product owner. Thus, change management is continuous throughout the product and sprint lifecycle.
Coaches work with individuals and teams to help them accomplish more than they could working on their own. As with professional sports teams, even very experienced development teams need coaching because they are usually too busy and too focused on execution and delivery to see larger, systemic factors affecting their performance. A coach in sports is NOT a player, and thus, can devote all their time to watching how the game is being played rather than focusing on delivery.
Continuous Deployment
Similar to continuous integration except that the process does not stop at simply integrating the code into the mainline branch. Each time code is checked in, it proceeds through the process of continuous integration and continues on with all other aspects of testing and acceptance and forward into production. This most frequently happens in an automated fashion.
Continuous Integration
The practice of integrating code into the mainline branch as it is checked in rather than batching up changes and integrating at a future time together with other code changes. As changes are committed, integration and regression testing are taking place to ensure that new code works properly with existing code. Most frequently, the entire process is automated so that it takes very little time in execution and there are fewer mistakes due to operator error.
Cross-functional
A development team is cross-functional when the team as an entire unit has all the skills necessary to produce a shippable product increment during each sprint. To be considered “shippable,” the product increment must meet the definition of done. This often requires many different skills such as coding, testing, database, user experience design, services, documentation specialists, business analysis, and many others. These skills may be represented throughout the team or possibly within a single individual who has multiple skills themselves.
Cumulative Flow Diagram
A chart that shows the number of items in each state of a Kanban workflow over time. It can be helpful in communicating the length of time it takes (on average) for items to progress through a particular state or the entire system. The CFD can also help to see pinch-points where there are constraints in the flow through the system.
The group or individual who derives direct benefit from the product. Customers can be internal or external. They can be clients for whom a product is custom tailored or vast numbers of users for whom the features are designed to please the greatest number based upon demand and necessity. In the case of very large customer groups, segmentation of the marketplace may be necessary to understand key features and demand priority. This helps to understand where the greatest return on investment will be. The saying “The customer is ALWAYS right” is flawed because there is seldom one sole customer or a completely aligned notion of demand across the population of all customers.
Cycle Time
The time an item spends in a particular state within a Kanban workflow; most commonly representing the time the team actually spends working on the item, not the time the item spends waiting in the system.
Daily Scrum
A meeting where the entire Scrum Team discusses (very briefly) the state of their development efforts on the product. Traditionally, the development team discusses what has been done since the previous meeting, what is intended to be done before the next meeting, and anything that may be blocking completion of items on the sprint backlog. The ScrumMaster acts as a facilitator to ensure the daily Scrum runs smoothly and the team stays focused on the agenda and purpose of the meeting, and also takes note of any impediments mentioned so that they can shepherd those impediments to resolution. The product owner is there to listen in on how things are going and thus receive status updates on whether the team will meet their sprint goal or not. The meeting is intended to be 15 minutes or less. Doing so allows the team to conserve the time that would normally be spent in the traditional weekly status meeting. They don’t engage in both; only the daily Scrum. Oftentimes, the team will use a parking lot chart to capture topics that don’t require the input of everyone on the team and that fall outside the scope of the three-question format.
Daily Standup
Another name for the daily Scrum. Teams began standing for their daily Scrum to reinforce the fact that the meeting should be very short. When we stand for longer than 15 minutes, it is usually uncomfortable on our bodies. This reinforces the idea that the meeting should be brief and to the point.
The primary objective of each sprint is to produce a shippable product increment; that is, features that deliver tangible value to the customer. In order for there to be tangible customer value, product backlog items must be completely done and ready to be shipped. To help understand if a PBI is truly DONE, the definition of done helps align the expectations and understanding of everyone on the team. Beginning with meeting the acceptance criteria, the DoD can include many different activities to ensure that PBIs are complete, high quality, and that there is little or no accumulation of technical debt.
Development Team
A cross-functional, self-organizing team of motivated individuals who work together in an entrepreneurial manner to ensure success as a team as they perform all of the creative work to deliver the value of a product to the customer. The development team traditionally has five to nine people (7 ± 2) so that there is adequate representation of the skills necessary to produce shippable PBIs and so that each team member is intimately aware of what all the other team members are working on. They are dedicated full-time to a single Scrum Team for the duration of the product lifecycle so that they may eventually become a high-performing team.
Distributed Teams
Per the Agile Manifesto principles, the best communication is face to face. To enable the highest degree of face-to-face communication, the teams need to be co-located or located in the same place. Teams that are not in the same place are considered to be distributed, although dispersed or scattered is probably a better term. There are varying degrees of co-location: everyone in the same “team room,” the same cubicle area, the same floor in the building, the same building, the same campus, the same city, the same state, the same time zone, the same country, the same continent ... the same planet. Distributed teams suffer from issues that co-located teams do not, mostly around communication. Team dynamics are tough enough as it is with teams that are together. Introducing added factors associated with distributed teams exponentially compounds the issues.
The idea that an individual can know and maintain a network of family, friends, and colleagues such that they know the interactions and relations between each of the individuals but only for a group of about 150 to 200 people. This principle can be used to identify the maximum size of a business unit or division working on a single application; that is, no more than 150 to 200 people. This would be about 15 to 20 teams total using the recommended development team size in Scrum of 5 to 9 people.
Elevator Pitch
A brief statement that summarizes the purpose, value, features, key differentiators, competitors, and other factors for a product so that stakeholders are clear as to what the product is about. It is nicknamed “elevator pitch” to enforce the idea that it should be very short but to the point such that the idea could be sold to someone in the brief time represented by an elevator ride together.
Empirical Process Control
In contrast to a fully defined process, an empirical process relies on visibility (transparency), inspection, and adaption in order to formulate smaller, manageable chunks of planning that seek to test an assumption. For instance, we have a product backlog item, which is an assumption of what the customer will find valuable with some criteria for acceptance, but NOT a fully defined implementation plan. The feature is elaborated further during a sprint, and the end result is validated against the customer’s expectations by way of a formal acceptance during the sprint review. In a defined process such as SDLC or waterfall, ALL details of the feature would be defined before any coding work could begin on the feature, with the goal being to anticipate all possible contingencies and scenarios up front.
End User
The person or group of people who will actually be deriving the value and benefit from the product. End users typically have some problem that they would like to solve and would like to use a machine (computer) to solve it for them. This could be the need to perform repetitive tasks, store vast amounts of data, make computations much faster than a human could, etc. The instructions that guide the machine are represented by the software that is created in the product.
An approach to software development focused primarily on engineering practices as a means of creating the product in an iterative and incremental manner. It includes such patterns as test-driven development, pair programming, continuous integration, system metaphors, and many others.
Facilitation
When groups get together to have discussions, etc., they often experience difficulties sticking to their agenda when everyone in the meeting has an opinion and is actively involved in the discussion. All meetings and activities can benefit from having a facilitator whose main purpose is to ensure that the group has an agenda and that they are making progress toward accomplishing their agenda. It is also the facilitator’s job to open the space, maintain the space, and close the space. A skilled facilitator will use many different techniques and approaches to help guide and shepherd the group without influencing them in any way.
Fibonacci Series
An infinite numerical sequence in which two sequential numbers are added to produce the third. The series begins with 0, 1, 1, 2, 3, 5, 8, 13, 21, 34 ... Modified versions of the sequence have been popular for use as a rating scale in assessing relative size of product features. Each number in the series is significantly greater or lesser than the other adjacent numbers. The Fibonacci numbers are commonly used on playing cards to engage in the activity called planning poker (or estimation poker).
Forte’s Principle
Summarized as “Delay no more!,” Forte’s principle emphasizes that when there is a critical decision to be made, the best course of action is to meet it head on by taking action in the most bold and confident manner possible. For instance, when giving a talk and faced with a large audience, the best action is to state something shocking.
Golden Circle
A pictorial representation of how to approach the overall creation of products by beginning in the center with WHY” and moving outward to WHAT and then finally addressing HOW. The concept was proposed by Simon Sinek in his book Start With Why. It is helpful in understanding the different concerns of the business (product owner) and IT (development team), which are best focused on why/what and how, respectively.
The idea that as a measure becomes a target, the measure ceases to be useful as a measure. For instance, if an organization uses the number of defects found in a product as a measure of performance for testers, and consequently, the determining factor of how large their bonus will be, then the testers will inherently log more defects than are necessary. Because they are generating frivolous defects, they are no longer a sound measure of the quality in the product.
Hardening Sprint
Generally considered to be a harmful practice, a hardening sprint is used to perform activities such as integration, testing, documentation, planning, performance testing, architecture design, and many others. The generally accepted best practice is to “speed up by slowing down,” that is, instead of having hardening sprints, have a more rigorous definition of done, which includes EVERYTHING that is needed at the feature level to make it shippable, even though the initial perception is that the team is slowing down. In reality, they are paying down technical debt instead of accruing it and paying it all in the so-called “hardening sprint” when almost no customer value is being delivered.
Ideal Days
A unit of estimation using time to express how long something would take if there were no ancillary activities, interruptions, etc., involved and the team could focus 100 percent on that particular task or feature. For example, in a perfect world, it might take a development team two days to complete a feature. However, the elapsed time once the feature was actually completed might be closer to three to four days with meetings, interruptions, and other activities involved.
Impediment
Something that prevents accomplishment of a goal or forward movement toward a goal. Also known as a blocker, roadblock, issue, etc. The ScrumMaster shepherds impediments to resolution on behalf of the development team members so that they may continue working on other features or help others who are working on other features.
Charts, diagrams, and other items that are displayed openly in team rooms, hallways, and other areas of the office such that anyone who views them can consume the information that is being communicated passively. The idea of a radiator is that it is stationary and gives off heat. If people want to warm themselves, they can go closer to the radiator and bask in its energy. The same is true with information radiators. This is in contrast to reports that are pushed out via e-mails or other reports/key performance indicators (KPIs) that are executed by the inquirer. Information radiators are passively distributing information.
Input Queue
A place where items can be freely and openly added on to a Kanban board by anyone at any time. These items have not been reviewed or evaluated in terms of priority, value, or order. Prior to any of these items being worked on, they would need to be discussed and a rough idea of sizing assigned by the development team. In Scrum, the product owner would pull items from the input queue and put them on the product backlog.
INVEST
An acronym introduced by Bill Wake in his 2003 article “INVEST in Good Stories and SMART Goals,” which provides some high-level guidelines related to product backlog items. The letters stand for Independent, Negotiable, Valuable, Small (or Sized Appropriately), and Testable.
Kanban
A system that turns a push-based system into a pull system by defining workflow states and assigning work in progress (WIP) limits to each state. The only circumstance under which a WIP limit may be violated is when an item is placed into the expedite queue, which itself has a WIP limit, which is absolute. Metrics such as cycle time and lead time help understand the time it takes for work to move through the workflow from one state to another. These seek to identify bottlenecks so that additional analysis may be conducted. There is also a chart called a cumulative flow diagram, which helps to show pinch-points and graphically represent lead time and cycle time. Kanban itself is a Japanese word meaning “card” and refers to the signaling mechanism used for responsibly controlling flow.
Task board, Scrum Board, Agile board, and Kanban board are often used interchangeably to mean the same thing: a workflow is defined, such as To Do, Work in Progress, and Done, and then items are tracked as they move from To Do to Work in Progress to Done. In reality, in order for the chart to be considered Kanban, there must be WIP limits on each workflow state. However, referring to the board as Kanban is generally understood to mean the same task board.
Kirchhoff’s Law
The current flowing out of all the various branches of a node must be equal to the current flowing into the node from all the various incoming branches to the node. Just seeing if you were really paying attention. This has nothing to do (specifically) with Agile or Scrum.
Manager
An individual who is responsible for other individuals in terms of their performance and execution within an organization. The manager is usually the one who hires their direct reports, often due to their background in the functional area or discipline for which they are a manager. They direct the employees in their charge and ultimately are required to evaluate and control the employees to some degree. Managers quite often are NOT actually doing the deliverable work, but rather, supervising the work that is being done.
Miller’s Law
The idea in psychology that the human brain is capable of maintaining 7 ± 2 pieces of information at a time for immediate recall. This principle has been applied to the size of Scrum Teams with the intention of keeping work in progress in the forefront of the team members’ minds; that is, being able to immediately know what everyone else on the team is working on at any given moment.
Net Promoter Score
A measure of the degree to which a product is supported and evangelized by its consumers. Responses to the following question are recorded: How likely are you to recommend this product to someone else? The resulting net promoter score is then calculated by subtracting the percent of negative scores from the percent of positive scores. For example, assume there are 20 respondents: 5 score 9 or 10; 13 score 7 to 8, and 2 score 0 to 6. NPS = 25% – 10% = 15%.
A ranked list of items from #1 to #n in terms of value, such as the product backlog. This is in contrast to saying that the list is prioritized, which usually means categorized in terms of a broader classification of importance, for example, high, medium, low. In the latter case, there can be MANY high-priority items. This does not help in terms of understanding which one to work on first, second, third, etc.
Pair Programming
A practice where two developers work closely together at one machine with one coding a solution and the other reviewing and testing as the solution is being developed. Frequently, the pair will switch roles for the next feature they work on together. The practice is counterintuitive in the sense that it seems wasteful to have two people working on the same thing at the same time. However, the reality is that the code produced is of such high quality that there is very little rework, which actually equates to a cost savings in having the pair work together.
Parking Lot
A technique for regulating and tailoring conversations, which allows for out-of-scope topics to be addressed at a later time, perhaps in the same meeting if there is an opportunity. An area of a whiteboard or a flipchart page is typically labeled “Parking Lot,” and attendees to the meeting or the facilitator will add the out-of-scope topics as they arise. The facilitator then curates the items throughout the meeting and brings the items to a conclusion or discusses next steps for addressing them prior to the departure of the attendees.
Parkinson’s Law
The idea that work expands to fill the timebox allocated for its completion. If someone is given two days to do a task, it will take two days. If they are given a day to do the same task, it will take a day. This concept is used by coaches and Scrum enthusiasts to underscore the idea of keeping and enforcing the integrity of the sprint timebox. That is, don’t extend the timebox because the team will be inclined to think “We don’t have to worry because if we are running behind, we can just extend the sprint each time.
Also known as the Deming Wheel, PDCA stands for Plan, Do, Check, and Act and outlines a cyclical method of performing work and receiving feedback on the work product and the actual performance of the work. These feedback loops help establish an empirical process, which focuses on inspection and adaptation instead of following a comprehensive, fully defined plan, which is established up front and adhered to regardless of the outcomes or discoveries made along the way.
Permutation Formula (Lines of Communication)
To figure out how many lines of communication there are between one node and every other node in a group of people (for instance, a team), the permutations formula can be used: (n – 1)n / 2. This formula illustrates that as team size increases in number, the lines of communication increase geometrically to the point where effective one-on-one communication on a daily basis is not possible, nor effective.
Planning Poker
An estimating method that uses cards that have the estimating units printed on them so that the participants take an impromptu vote on the value they are indicating rather than openly reveal the values one by one, thereby anchoring each other to previously mentioned values. The spontaneous nature of planning poker ensures that true estimates are captured instead of gravitation around what an “expert” or person of authority thinks.
Portfolio Manager
An individual who controls the assets and liabilities of a portfolio such that they are investing on behalf of the organization. The portfolio often includes some theme or criteria by which these investment instruments are aligned.
Prioritized
Priority is often expressed in terms of high, medium, or low or similar general levels of importance. When there is only a handful or two of items to prioritize, this method might be sufficient as a means of communicating importance. However, when there are tens or hundreds of items, a more granular method such as order or rank is necessary. If there are 20 to 30 high-priority items, it is unclear what should be done first or next, etc. It’s not helpful to the development team if EVERYTHING is high priority.
A list of features, defects, and other items related to the development and maintenance of a product. The list is ordered by value with the first most valuable item at the top, then the second most valuable item, and so forth down the list. The items have acceptance criteria and estimates for at least those that could be pulled into a sprint and ideally for all those targeted for the release.
Product Backlog Item
Also known as PBI, this refers to the various different items that comprise the product backlog, which might include new features, defects, support requests, technical debt, team improvements, and other product-related increments of value. PBIs can be expressed in several formats. The most common format is user stories. Some organizations have had positive results with the use-case format to express PBIs.
Product Demo
Usually occurs during sprint review but is only part of the sprint review. The product demo shows the product increment that was created during the sprint so that the stakeholders in attendance have an opportunity to review and provide feedback. It is also the official opportunity for the product owner to examine the product increment.
Product Lifecycle
A product’s lifecycle is essentially indefinite. The hope of all who develop products is that their product will last 10, 15, 20, maybe even 30 years. Windows, for instance, has been around for about 25 years and has gone through many revisions, versions, etc. Someday, Microsoft might “sunset” Windows and replace it with another completely different product. During the product lifecycle, there can be many different projects.
Product Manager
An individual who solely selects the direction for a product based on analytical methods such as market research and trend analysis, and sometimes actual input from customers via direct interaction with each customer or with a sample of the customer population or market segment. Product managers usually set strategy and direct project managers and project teams in terms of what to create. This is in contrast to a product owner who works together with development teams to ensure that the end product delivers the highest customer value possible.
One of the three key roles on the Scrum Team, which represents the customer/client and the business side of the organization in general. The product owner must be someone who is empowered to make day-to-day executive decisions on the product they are responsible for. They must also have some direct contact with the customers whom they represent so that they are able to translate the needs and wants of the customers into product backlog items.
Product Roadmap
A high-level plan that briefly outlines goals, focus areas of an application, and classes of user who will be served for various releases throughout the year. The roadmap is typically updated quarterly or after each release with new information about the various other releases. The period of a year is a moving window wherein the roadmap always covers a 12-month view of upcoming releases, for instance.
Product Vision
A statement that captures the essence of what a product is about at a very high level. It can include mention of the market, key differentiators, key customers, the class of good/service that the product represents, competitors, etc. The elevator pitch template from Geoffrey Moore’s book Crossing the Chasm has often been used as an example of a starting point for creating a product vision when the product owner is stuck or having a difficult time articulating the key characteristics of the product.
Program Manager
In traditional project management, a program manager is responsible for a collection of projects that are aligned to a common purpose and share a common high-level budget. Programs are then aligned to strategic initiatives and funded as such. This model attempts to map and track from initiative to project-level work.
Project Lifecycle
A project has a definite beginning and a definite end. It also has a definite scope and cost associated with it. For the purposes of Agile project management, projects can be used by the product owner as a means of securing finance for the product development effort. As such, there can be many formats for projects: monthly, quarterly, yearly, per sprint, per release, etc.
Project Management Office (PMO)
In projectized organizations, the PMO is responsible for evaluating project charters, determining return on investment (ROI), allocating funds, and other strategic governance functions related to projects and programs. Not all organizations have a PMO.
Project Manager
Traditionally, a project manager has been responsible for tracking scope, cost, and time for project-related work. They are knowledgeable about project management practices, oftentimes as outlined by the Project Management Body of Knowledge from PMI, with no requirement of knowledge about the actual product or service being developed.
Refactoring
When the form of the code is improved in terms of removing unnecessary spaces, comments, clumsy logic structures, multiple nested loops, and other patterns that cause code performance to decrease. The overall end-to-end functionality from the user’s perspective does not change apart from perhaps a noticeable increase in efficiency and performance. Refactoring regularly throughout the product development lifecycle is an expected, positive practice. It’s akin to keeping the kitchen clean as you prepare a meal rather than preparing the entire meal and THEN cleaning the kitchen: BIG job and along the way, the mess may have interfered with your ability to keep ingredients pure, etc.
Relative Estimating
An estimating method that uses a scale to compare the complexity of items in relation to each other, rather than attempting to guess at an exact value from an absolute scale, as in absolute estimating. Oftentimes, a modified Fibonacci sequence or T-shirt sizes are used. Theoretically, there is no correlation between relative estimates and absolute estimates.
When a product owner decides that the product increment has enough shippable value to deliver to their customer(s), the product increment will be released into production. The size and frequency of releases can vary significantly. For instance, for one organization, a release might make sense for each sprint. For other organizations, it may only make sense from a business perspective to release every three sprints. Some organizations release on a quarterly schedule. Other organizations conduct releases based upon scope, not dates; when they have the minimum viable product (MVP) they deploy the initial release and then strategically target features sets for future releases, which happen as those feature sets are complete.
Release Backlog
The portion of a product backlog that is targeted for release. If the release is date driven, the release backlog will be an estimated amount of scope that may be completed. If the release is scope driven, then the release backlog will be fixed and the date will be estimated. Only the release portion of the backlog will have acceptance criteria and estimates. Anything beyond the upcoming release is too speculative to waste time on detailed elaboration of acceptance criteria and estimates until it becomes imminent.
Release Burndown
A chart that indicates progress toward a release goal of reaching zero given an initial, cumulative size for the release. The chart is updated after each iteration with the remaining cumulative size of product backlog items that must be completed. Various different units may be used such as story points, ideal days, or simply the number of product backlog items.
Release Planning
An activity in which the product owner and development team work together with the help of the ScrumMaster to understand what will be targeted for release to the customer, that is, put into production. Releases can be driven by date or scope. During release planning, the Scrum Team would identify whether the driving factor is an MVP represented by a fixed set of functionality or by delivery date. It is not possible to know both the exact scope AND the exact delivery date.
A term that has been widely used to mean the application of Scrum to large, complex product development efforts requiring multiple development teams.
Scrum
Created by Jeff Sutherland and Ken Schwaber, Scrum is an empirical approach to raising transparency in product development, which focuses on inspecting and adapting to provide regular intervals of customer feedback. The name is borrowed from the rugby formation in the spirit of emphasizing the coming together aspect of the framework. There is also heavy influence from Takeuchi and Nonaka’s influential 1986 paper in the Harvard Business Review entitled “The New New Product Development Game.”
Scrum Board
Another name for a modified and simplified Kanban board. Scrum Boards typically include only three workflow states (or variations on these): To Do, Work in Progress, and Done and do not feature WIP limits on these states, as Kanban requires.
Scrum Team
The central focus of product development, which includes three separate but equal roles: product owner, development team, and ScrumMaster. Each of the three roles is dedicated full time to the Scrum Team so that there are no conflicting priorities. The roles of the Scrum Team have distinctive functions, but the spirit of product development follows the idea that none of the roles functions in a vacuum; quality and value delivery are EVERYONE’S responsibility.
ScrumMaster
The Scrum Team role that ensures all impediments are removed and that the entire Scrum Team has everything it needs. The ScrumMaster’s responsibilities cross many functional boundaries, such as coach, counselor, advocate, protector, defender, mentor, teacher, leader, servant, etc. The ScrumMaster best serves the Scrum Team when they are dedicated full-time to a particular team. When this happens, the ScrumMaster is able to invest ALL of their time making that one team GREAT.
The idea that people are motivated best when they are trusted to manage themselves rather than being held accountable by another employee who is hierarchically superior to them. Self-managing teams have individuals who hold each other accountable and whose primary interest is in seeing the team accomplish its goals.
Self-organizing
Teams that decide for themselves who will do what work based upon the best fit for the work in terms of skills and availability AND what sequence in which to do the work demonstrate the characteristic of self-organizing. Some people use this term synonymously with self-managing. However, self-organizing relates more to execution than to governance or team structure, although they are somewhat related.
Shippable Product Increment
From the very first iteration, features are delivered that could be put into production such that they work from end to end and demonstrate customer value. These features, although usable by the customer, may not truly delight the customer because the product overall is incomplete from their perspective. Thus, each iteration (sprint) delivers an additional increment or batch of value to the overall product such that the overall product becomes increasingly more complete from the customer’s point of view. At some point, after numerous iterations/increments, the business (product owner) will make the decision that the product will be shipped, and there is zero delay or additional effort required to make that happen because each iteration has been ensuring that the overall product is shippable all along the way.
SMART
An acronym often used to describe goals or tasks as Specific, Measurable, Assignable, Realistic, and Time-related. There are MANY variations on the adjectives selected for the various letters, some of which depart from the originally intended meaning of the acronym (arguably). The acronym was mentioned in a classic article by Bill Wake: “INVEST in Good Stories and SMART Tasks.”
A view of how groups can interact when their relationships and other dynamics are defined in various ways. The central concept is around building communities of practice, which are more durable and interactive autonomously and thus more prone to organic interaction and ad hoc discovery, innovation, etc.
Sprint
A fixed timebox or iteration that repeats during the product development effort. Throughout the sprint, the team is engaged in delivering customer value in accordance with the product backlog items they have selected. The result of the sprint is a shippable product increment (SPI). Each subsequent sprint’s SPI would add to the overall SPI until the product owner decides to release the overall SPI.
Sprint Backlog
The overall collection of all features, defects, enhancement requests, service requests, technical debt, and all other work associated with the product at hand. The product owner is primarily responsible for ensuring that the product backlog is continuously updated with new requirements, changing priorities, and other factors that have an impact on the delivery of the highest customer value in the product. The product backlog continues to grow over time and never goes away until there is no longer a product to support.
Sprint Burndown
A chart that shows work remaining at various intervals throughout the sprint lifecycle. The units can vary widely from hours, which are most often used with tasks, to simply the number of tasks, story points, and simply user stories from the PBL.
Sprint Burnup
A chart that shows features that have been completed today as a cumulative amount of functionality delivered. This measure can be useful from a business perspective in assessing whether there is sufficient customer value to deliver to the customer or not.
Sprint Goal
A statement of what the sprint intends to accomplish beyond just a random set of selected product backlog items. The sprint goal helps to ensure that the entire Scrum Team is on the same page and that they can quickly and easily communicate the purpose of the sprint to other stakeholders.
The official activity in Scrum where the Scrum Team examines what is on the product backlog in terms of the highest valued items for the customer at the present moment and decides what could be done within the next sprint. They also determine what the Sprint Goal would be that reflects what they are working on for the sprint. The sprint planning meeting should be proportional to the duration of the sprint as given by the following formula: sprint planning meeting duration = 2 hours/week of sprint duration.
Sprint Retrospective
The official activity in Scrum where the Scrum Team reflects on its own working behaviors, events of the previous sprint, working agreements, definition of done, and other important team dynamics so that it may identify things that have worked well, things that have not worked well, and any experiments it would like to try for the next sprint by way of improving. The sprint retrospective should be proportional to the duration of the sprint as given by the following formula: sprint retrospective = 1 hour/week of sprint duration.
Sprint Review
An official activity in Scrum where the Scrum Team shares with stakeholders what the sprint goal was, if it was accomplished, what features were selected for the sprint backlog, and which (if any) were NOT completed; explains what happens to those that are not completed; and conducts a product demo that shows the functionality delivered in accordance with the sprint backlog and sprint goal. This is the official opportunity for the product owner to express acceptance of each sprint backlog item. The sprint review should be proportional to the duration of the sprint as given by the following formula: sprint review = 1 hour/week of sprint duration.
Sprint Zero
A practice followed by some teams wherein they put preparatory work in a “sprint” at the very beginning of the product development lifecycle that delivers no actual customer value. Oftentimes this is done because the team does not want to be penalized for not delivering any customer value or because they won’t get credit for the work performed (see Spinal Tap: “But ... This one goes to 11 ...”).
A method of describing complexity in an organization’s structure across two dimensions: agreement and certainty. The exact parameters upon which the organization is agreeing or is certain tend to vary depending on what version of the diagram is used. From an Agile perspective, a diagram is frequently used to illustrate that most organizations are not simple, but rather fall into the complex domain and thus, can benefit more from an empirical process such as Scrum than from a fully defined process like SDLC, waterfall, or traditional project management as laid out by the PMBOK Guide. It was first cited relative to Scrum in Ken Schwaber and Mike Beedle’s book Agile Software Development with Scrum.
Stakeholder
Someone who has a vested interest in a product, project, or similar undertaking. Internal stakeholders can be within the organization executing on the undertaking, or external stakeholders can be outside the organization. Some examples of internal stakeholders might be executive management, sales, marketing, an internal customer, etc. Some examples of external stakeholders might be vendors, partners, outside agencies, customers, clients, etc. One of the most critical groups of stakeholders involved is those who are defining the requirements (often the product owner) and those who are implementing the solution (development team).
Status Meeting (Weekly)
A traditional meeting where a group of people get together to communicate what they have been working on for the week and any concerns, issues, risks, etc. Oftentimes it is held at the end of the week in the afternoon or on the following Monday for the previous week. The efficacy of this meeting is dubious because there is little opportunity to make changes or deal with risks and issues as they arise during the week. Also, due to its formality, the status meeting often gives rise to elaborate reports and preparation wherein the participants are more focused on what they will be saying than on what is being said in general and the bigger picture. It is often scheduled for one to two hours.
Story
The shortened version of user story, which is often used interchangeably to refer to product backlog items, although user stories are merely one form of PBI.
An estimating method that uses a point scale to indicate relative sizes of items in relationship to each other, usually based upon complexity. Frequently, a modified Fibonacci sequence is used, as is powers of two.
Task Board
A method of tracking backlog items through various states of completion in a predefined workflow. Sometimes referred to as a Kanban board; however, this is not 100 percent correct. A Kanban board (and workflow) would have set work-in-progress limits for each of the workflow states. This is how a standard workflow moves from being a push system to a pull system. Without the WIP limits, it’s simply a workflow. The simplest example of a task board would have three states: To Do, Work in Progress, and Done.
Team
Typically, when people refer to just the team, they really mean the development team. However, it is always a good idea to get clarification as to whether they mean Scrum Team or development team in conversations, because there is a clear distinction between responsibilities of the development team vs. general overall responsibilities of the Scrum Team.
Technical Debt
Technical debt assumes many different forms, but the net result is invariably the same: accumulated work affects the ability of a team to deliver working software to production in the similar way that credit card debt continues to accrue until the limit on the card is reached and MUST be paid off.
Test-Driven Development (TDD)
An approach to creating software that focuses on writing automated tests first, which ensure that the code meets the acceptance criteria for the feature. The tests are then executed, and because there is no code yet, they all fail. Code is written in an attempt to make the tests pass. However, the first pass is usually not 100 percent successful, and the test will fail again. Thus, more code is written and the cycle repeats itself until all tests pass. At that time, the code has demonstrated that it meets the acceptance criteria.
Theory of Constraints
The idea that there will always be at least one limiting constraint (and usually more) that are unavoidable and thus, the constraints must be identified and then systems built around and optimized for these constraints.
A constraint placed on an event such that when the allotted period of time has expired, the event is officially over. A two-week sprint is an example of a timebox, which says that when the two weeks are up, the sprint is over. The sprint planning meeting for a two-week sprint is timeboxed to four hours (two hours/week of sprint duration).
Tools
Various different items that provide support to the product development effort and aid the Scrum Team in following Scrum practices. Sharpies and stickies are tools. A task board is a tool. There are also many different electronic tools that provide virtual analogues of their physical counterparts: task board, product backlog, story cards, etc.
Trade-off Matrix
A visualization of the three factors of product development: scope, cost, and time as fixed (non-negotiable), firm (optimized), and flexible (no limit). Only one of these may be known for certain. One of the other two can be optimized as long as the third has no limitation. For example, if scope is fixed (non-negotiable), then we can optimize for time (date) by making cost unlimited. In that scenario, we would be willing to pay any amount of money necessary to produce the non-negotiable scope by the desired delivery date. This might include adding more people to the product team or offering an incentive to the existing team to work extra in order to meet the desired delivery date.
Triple Constraint
Three fundamental factors associated with all product development efforts that are directly related to each other. Increasing scope results in increased time and/or cost.
Tuckman Model
Four stages of group dynamics commonly known as forming, storming, norming, and performing, which were described by Bruce Tuckman in his 1965 Psychological Bulletin article “Developmental sequence in small groups.” When groups experience changes to their composition, they frequently regress to a former stage in the development cycle. Thus, it is best to keep the team together as a unit with as few disruptions and changes to their composition as possible.
A template that can be used to answer pertinent questions about a feature so that the team delivering the feature is clear on what is expected. Details may include the following:
Title: an active-verb goal phrase that names the goal of the primary actor
Primary Actor
Goal in Context
Scope
Level
Stakeholders and Interests
Precondition
Minimal Guarantees
Success Guarantees
Trigger
Main Success Scenario
Extensions
Technology and Data Variations List
Related Information
User Story
An approach to creating high-level product requirements, which includes information covering the most pertinent business case questions: who, what, and why. The most widely used format today is based upon the template created by a team at Connextra in 2001. The ultimate goal of a user story is to have enough of a vision for the feature to begin working on it and an understanding of when it will be considered done. There is also an understanding that the more pertinent, intimate details of the feature will emerge during its creation.
Velocity
The average amount of features delivered that meet the definition of done per sprint. The velocity can be measured using various different units, with the two most common being story points/sprint or product backlog items/sprint.
In general, describes the nature of stage-oriented, single-pass software development methodologies. The work done in each stage of the workflow is isolated from the other stages, oftentimes with a formal sign-off process similar to the levels of a waterfall; water never travels back up to other stages in a waterfall.
Working Agreements
A very lightweight set of ground rules for establishing protocols among teams or other parties, for example, client and consultant. Working agreements are used to ensure that everyone is clear on what is expected, customary, acceptable, etc., in terms of conduct. For instance, there might be working agreements that talk about when the daily Scrum takes place, what happens when someone is late, who fills in for the ScrumMaster if they are out, whether the product owner participates in the daily Scrum or not, and many other factors within Scrum. By having clear working agreements, much of the angst and strife in teams can be mitigated.
Work Breakdown Structure (WBS)
An elaboration of all features and functionality down to the work package or task level for the purpose of seeking estimates from “resources.” The PM then uses the cost of those resources and estimates to calculate costs for each task and, finally, the cost for the entire project.
Work in Progress/Work in Process (WIP)
A status within workflow states of a Kanban system that indicates when items are actively being worked on in that state. WIP can also be a state itself in very rudimentary workflows, such as To Do, WIP, and Done.