# Gemini ## The Hierarchy of Agile Requirements In the context of Agile software development, which is an iterative approach to building software, requirements are not defined all at once at the beginning of a project. Instead, they are broken down and detailed progressively. This process of breaking down large, abstract ideas into small, concrete tasks follows a clear hierarchy, typically involving three main levels of granularity. These levels, from the largest and most abstract to the smallest and most specific, are Epics, Features, and User Stories. This hierarchical structure allows teams to manage complexity, maintain focus, and adapt to changing needs throughout the development lifecycle. ### Epics: The Grand Vision At the highest level of this hierarchy is the **Epic**. An Epic represents a very large body of work, a significant, high-level goal or initiative that is too broad and complex to be completed in a single development cycle, known as a sprint. Epics are intentionally vague and lack fine-grained detail. They serve as placeholders for major new business services, the creation of an entirely new product, or the introduction of a substantial new capability to an existing product. For example, an epic might be "Implement a complete e-commerce checkout system" or "Develop a user profile and social networking module." Because of their large scope, epics often span multiple sprints, and sometimes even multiple quarters. They are not yet broken down into actionable tasks for developers; their primary purpose is to capture a strategic objective and provide a container for more detailed requirements that will be defined later. ### Features: Tangible Capabilities The next level down from an Epic is the **Feature**. A feature is a distinct piece of functionality that delivers value to the business or end-users. It is a more concrete and defined component of an Epic. While an Epic might be "Implement a checkout system," a feature within that epic could be "Pay with a credit card" or "Manage shipping addresses." At the feature level, the requirements become more specific. There is a clear association with a business objective; the team understands the role this feature plays in the overall business case for the product. The **Product Owner**, the individual responsible for maximizing the value of the product resulting from the work of the development team, must have a very clear understanding and perspective on each feature. They are responsible for ensuring that the feature aligns with stakeholder needs and contributes to the product's goals. By the time an idea has been refined from an Epic to a Feature, it has moved from a vague strategic goal to a well-understood, valuable capability that can be further broken down for implementation. ### User Stories: The Unit of Work Features are, in turn, decomposed into one or more **User Stories**. A User Story is the smallest unit of work in an Agile framework and represents a complete, self-contained piece of user-facing functionality. Its purpose is to articulate how a piece of work will deliver a particular value back to the customer. User stories are typically written from the perspective of an end-user and follow a specific format: "As a [type of user], I want to [perform some action] so that I can [achieve some goal]." This structure ensures that the focus remains on the user's needs and the value they will receive. For example, the feature "Pay with a credit card" could be broken down into user stories like, "As a shopper, I want to enter my credit card details so that I can complete my purchase." Initially, a user story might be a high-level description, but as it gets closer to being worked on, it is enriched with more detail, including specific acceptance criteria, to provide the developer with all the necessary information to build and test the functionality. User stories can sometimes be broken down even further into smaller sub-stories or technical tasks, especially if the initial story is too large to be completed within a single sprint. This entire process of decomposition, from Epics to Features to User Stories and finally to tasks, is a continuous flow. It is not a one-time activity performed at the project's outset. This progressive refinement is a core principle of Agile development. ## The Principle of Just-in-Time Refinement A critical aspect of managing this hierarchy of requirements is the concept of **Just-in-Time (JIT) decomposition**. This stands in stark contrast to traditional "waterfall" methodologies, where an exhaustive and complete set of requirements for the entire project is created upfront. In an Agile context, performing such a massive upfront analysis is considered wasteful and risky, as priorities and understanding can change over time. Instead of defining every epic, feature, and user story at the beginning, the team details them progressively and only when necessary. The process works as follows: the team maintains a prioritized list of work called the **Product Backlog**. This backlog contains epics, features, and user stories at varying levels of detail. The items at the top of the backlog, which are slated for upcoming sprints, are finely detailed. The items further down the list remain as larger, less-detailed epics or features. The team engages in a continuous activity called backlog refinement (or grooming), where they take the high-priority epics and features and break them down into user stories. These user stories are then detailed with acceptance criteria and other necessary information right before they are considered for inclusion in an upcoming sprint. This JIT approach ensures that the development team's effort is always focused on the most valuable and immediate work. It prevents time from being wasted on detailing features that may be deprioritized or fundamentally changed before they are ever built. The goal is to have a sufficiently deep pool of well-defined, "ready" user stories to choose from when planning the next sprint, while leaving the longer-term roadmap flexible. This dynamic decomposition and detailing allows the team to maintain a steady development pace, or "sprint cycle," without being bogged down by excessive upfront planning, thereby embracing change and delivering value more effectively. ## Characteristics of a Good User Story: The INVEST Model To ensure that user stories are effective units of work that can be smoothly integrated into a sprint, a set of guiding principles is often used, encapsulated in the acronym **INVEST**. These criteria help the team create well-formed stories that are clear, manageable, and valuable. INVEST stands for Independent, Negotiable, Valuable, Estimable, Small, and Testable. * **Independent:** A user story should, as much as possible, be self-contained and not have inherent dependencies on other user stories. If stories are tightly coupled, it becomes difficult to prioritize and schedule them separately. Independence gives the Product Owner the flexibility to reorder the backlog without breaking the system or creating complex development chains. While complete independence is not always possible, the goal is to minimize these dependencies to allow for maximum flexibility in planning. * **Negotiable:** A user story is not a rigid contract or a detailed specification; it is a *promise for a conversation*. It captures the essence of a requirement—the "who," "what," and "why"—but deliberately leaves the details of the implementation—the "how"—open for discussion between the Product Owner and the development team. This negotiability is crucial. For instance, a story might state a need for a secure password system. An overly prescriptive story might demand "16-character passwords with 3 special characters," which could force the team to build a custom authentication system from scratch if their chosen technology framework doesn't support that exact configuration. A more negotiable story would focus on the goal ("ensure strong password security") and allow the team to propose a solution that meets the goal while leveraging existing, reliable components. The negotiation allows the team to find the most efficient and effective way to deliver the desired value, balancing user needs with technical feasibility. Critical details, like those for a unique and essential widget, should be spelled out, but for most standard components, flexibility is key. The aim is not to "leave out important details" but rather to avoid specifying non-essential details prematurely, which could unnecessarily constrain the solution. * **Valuable:** Every user story must deliver tangible value to an end-user or the customer. The "so that..." clause in the user story format explicitly forces the team to articulate this value. This principle ensures that the team's effort is always directed towards work that contributes to the product's overall goals. It prevents the creation of purely technical tasks as user stories, which, while necessary, should be part of implementing a valuable feature, not standalone items in the backlog. * **Estimable:** The development team must be able to look at a user story and provide a reasonable estimate of its size or effort. This doesn't mean predicting the exact number of hours it will take, but rather giving a relative size (e.g., "this is about twice as big as that other story"). If a story cannot be estimated, it is usually a sign that the requirements are not yet well understood, the scope is too vague, or the story is too large and needs to be broken down further. The ability to estimate is a prerequisite for effective sprint planning. * **Small:** A user story should be small enough to be completed by the team within a single sprint. This is critical for maintaining a steady flow of work and getting fast feedback. Large stories that span multiple sprints increase risk, delay feedback, and make it difficult to track progress. If a user story is too large to be completed in one sprint (and certainly no more than two), it must be split into smaller, more manageable stories. The ideal size allows for several stories to be completed in a single sprint, demonstrating tangible progress. * **Testable:** A user story must be testable. There must be clear, objective criteria to determine whether the story has been successfully implemented. If a story's completion is subjective or cannot be verified, it's impossible to know if it is truly "done." This principle is directly linked to the concept of **Acceptance Criteria**, which are the specific conditions that must be met for the story to be accepted. The "Testable" criterion ensures that requirements are unambiguous and that there is a shared understanding of success between the developers, testers, and the Product Owner. ## Crafting Effective User Stories: An Example To illustrate the difference between a well-formed, negotiable user story and one that is overly prescriptive, consider the task of implementing credit card payments. **Version 1 (Overly Prescriptive):** "As an HR staff member, I want to pay for a job posting with a credit card so that I can have an efficient payment process. *Notes:* * Accept Visa, Mastercard, and American Express. * Consider Discover. * On purchases over $100, ask for the card ID number from the back of the card. * System can tell what type of card it is from the first two digits. * System can store a card number for future use. * Collect the expiration month and date of the card." This version contains a great deal of specific implementation detail. It hardwires business rules, such as the "$100" threshold for requiring a card ID, which might change. It dictates technical details, like deriving the card type from the first two digits. By fixing these details so early, it removes the team's ability to negotiate a better solution. What if the payment gateway they use has a different, more secure way of handling card verification? What if new card types emerge? These hardcoded details make the story brittle and difficult to adapt. **Version 2 (More Negotiable and Effective):** "As an HR staff member, I want to pay for a job posting with a credit card so I can have an efficient payment process. *Notes:* * Will we accept Discover cards? (This is a question for later discussion) * For UI: Don't need a field for card type; it can be derived from the card number. (This is a helpful hint, not a rigid constraint)" This second version is superior because it focuses on the core need while leaving the implementation details open for discussion. It captures important considerations as notes or questions, prompting a conversation at the appropriate time—when the story is being detailed for development. This allows the Product Owner and the team to make decisions based on the most current information and technical context. The story remains open and flexible, allowing for a more robust and maintainable solution to be built when the time comes to implement it. ## Defining the User: The Importance of User Roles The "As a [type of user]" part of a user story is not a mere formality; it is a critical component that defines the context and purpose of the requirement. A **user role** is a collection of defining attributes that characterize a specific population of users and their intended interactions with the system. It is a persona, not just a job title. Properly defining user roles is essential for creating meaningful and accurate user stories. Sometimes, different user roles may perform actions that seem very similar on the surface. For example, both a "System Administrator" and a "Content Manager" might need to delete articles. A common question is whether to combine these into a single user story for a generic "user." The answer is almost always no. Even if the action being performed (deleting an article) is the same, the underlying goal and the criteria for success (the acceptance tests) are likely different. The administrator might be deleting articles for system maintenance, while the content manager is doing so as part of their editorial workflow. The validation and logging requirements for these two actions could be completely different. Merging these distinct needs into a single, generic user story complicates the development and testing process. It forces the team to handle multiple logical paths and validation rules within one piece of work, increasing complexity and the risk of errors. It is far better to create two separate user stories, one for each role. This keeps the requirements clear and focused. It is crucial to understand that having two separate user stories does not necessitate two separate implementations. The development team might build a single, flexible "delete article" function in the software that can satisfy the requirements of both user stories. The user stories define the *what* and the *why* from the user's perspective; the implementation defines the *how*. The logging example from the lecture illustrates this perfectly: a requirement to "log all financial transactions" and another to "log all access to sensitive data" are two distinct user stories with different business drivers. However, they can both be fulfilled by a single, well-designed logging facility in the software. Therefore, when defining requirements, it is vital to consider the distinct user groups being targeted. Factors to consider include: * **What they will use the software for:** Their primary goals and tasks. * **How they will use the software:** Their workflow and interaction patterns. * **Their background and familiarity with technology:** A system for tech-savvy employees is designed differently from one for volunteers with high turnover and varying computer skills. In some cases, user roles can have relationships, such as a hierarchy. For example, "Editor" and "Writer" could be specializations of a more general "Content Creator" role. In such a scenario, there might be user stories that apply to the general role, and then more specific stories that apply only to the specialized sub-roles. Careful differentiation of user roles is fundamental to building a system that truly meets the needs of its diverse user base. ## The Dangers of Large Stories: Ambiguity and Hidden Complexity The principle that user stories should be small is not just about fitting work into a sprint; it is also a critical strategy for managing risk and ambiguity. The larger a user story is, the more likely it is to contain hidden assumptions, unstated requirements, and unresolved ambiguities. These issues often only surface during development, leading to delays, rework, and frustration. Consider the following seemingly straightforward user story: "As a website user, I want to post my resume so I can be contacted regarding job interviews." On the surface, this sounds simple. However, upon closer inspection, it is riddled with questions and ambiguities: * **What does "post" mean?** Does the user upload a file (PDF, Word)? Do they fill out a web form that generates a resume? Is the resume stored in a database? * **How is the user "contacted"?** The story says "so I can be contacted," which is a passive goal. Who is doing the contacting? Recruiters? Hiring managers? How do they find the resume? Is there a search function for them? * **What about privacy?** When a user posts their resume, are they making their personal details—name, address, phone number—publicly available to everyone on the internet? Or is access restricted? * **What is the mechanism for contact?** Does the system have a built-in messaging feature, or are recruiters expected to use the contact information directly from the resume? * **What does "regarding job interviews" mean?** Is this a strict limitation? Can a recruiter not contact the user for a preliminary chat? This single sentence, which might seem like a reasonable user story, is actually a high-level epic. It describes a major capability, not a small, actionable task. Attempting to develop this as a single unit of work would be fraught with problems, as the developer would have to make numerous assumptions about the answers to these questions. A better approach is to recognize this as an epic and break it down into smaller, more focused user stories, such as: "As a job seeker, I want to create a profile with my work experience," "As a job seeker, I want to upload my resume as a PDF file," and "As a recruiter, I want to search for candidates by keyword." Each of these smaller stories can be discussed, detailed, and implemented with far greater clarity and less risk. There is no magic, universal definition for the size of an epic versus a story. The key principle is that an epic is intentionally too big to be implemented in a single sprint (or even two). The process of agile development is one of continuous decomposition, breaking these large epics down into features, and then into stories, until they reach a size that is well-understood, estimable, and small enough to be completed within a single development cycle. For example, "As a user, I want to log into the system" could be a simple user story if it only involves a username and password field. However, if it implies a full identity management system with password recovery, two-factor authentication, and account creation, then it is clearly an epic that needs to be broken down into many smaller stories. ## From User Story to Action: Acceptance Criteria and Conditions of Satisfaction Once a user story is defined, it is not yet ready for development. To make it actionable and testable, it must be accompanied by **Acceptance Criteria**. Acceptance criteria are a set of specific, testable conditions that must be met for the user story to be considered complete and for the Product Owner to accept the work. They translate the general goal of the user story into a concrete checklist of expected outcomes. A closely related concept is the **Condition of Satisfaction**, which can be thought of as a high-level acceptance test that describes what will be true after the story is implemented. These conditions provide a clear, shared understanding of success. Let's consider the user story: "As a premier member, I want to be able to cancel my hotel reservation at any time so that I can save on cancellation penalties." To verify that this story has been successfully implemented, we can define a set of conditions of satisfaction, which would be written on the back of the virtual "story card" or attached to the story in a tracking tool. These might include: 1. **Verify that a premier member can cancel a reservation without a penalty being applied.** 2. **Verify that the hotel's system is correctly notified of the cancellation.** 3. **Verify that the premier member receives a confirmation (e.g., an email or in-app notification) that their cancellation request was successfully processed.** 4. **Verify that the member's account or credit card statement shows that no penalty has been charged.** These high-level conditions form the basis for the detailed test cases that will be executed. When the development team demonstrates their completed work at the end of the sprint (during the Sprint Review meeting), they will walk the stakeholders through these steps, showing how the system now fulfills each of these criteria. This process provides objective proof that the user story has been delivered as expected, moving beyond subjective claims of "it's done" to a verifiable demonstration of functionality. ## The Product Backlog: The Single Source of Truth All of this work—epics, features, user stories, and their associated details—is managed in a central artifact known as the **Product Backlog**. The product backlog is the master list of all requirements for the system. It is a single, prioritized list of everything the team might work on, representing the complete scope of the project. ### Key Characteristics of a Healthy Product Backlog A well-maintained product backlog is essential for a successful Agile project. It has several key characteristics: * **Value-Oriented:** Every item on the backlog, from the largest epic to the smallest story, should have clear value to the users or customers. The backlog should make this value transparent. * **Owned and Managed by the Product Owner:** The Product Owner is solely responsible for the content, availability, and ordering of the product backlog. They continuously work to ensure it reflects the current priorities and needs of the stakeholders. * **Dynamic and Living:** The backlog is not a static document created at the beginning of the project. It is a living artifact that evolves as the product is built. New items are added, existing items are refined, and priorities are constantly re-evaluated based on feedback and changing market conditions. The backlog exists for the entire lifetime of the product. * **Prioritized:** The backlog is an ordered list. The most important and valuable items are placed at the top, ready to be worked on next. The least important items are at the bottom. This prioritization guides the development team's focus. * **Transparent and Visible:** The product backlog should be accessible to all stakeholders and team members. This transparency fosters clear communication and ensures everyone has a shared understanding of what is being worked on and what is coming up. It is not a secret document held by the Product owner. * **A Single Source of Truth:** All work that the development team does must originate from the product backlog. There should be no "side channels" or informal requests. If a new idea or requirement emerges, it must be added to the backlog and prioritized against all other items. This ensures that the team is always working on the most valuable things, not just the most recently requested ones. * **Free of "Never" Items:** The backlog should not be used as a dumping ground for ideas that will never be implemented. While it's acceptable to have items with an unknown implementation date, items that are fundamentally inconsistent with the product vision or are known to be infeasible should not be added. The Product Owner should have the courage to say "no" to stakeholders and explain why an item does not belong in the backlog, rather than adding it just to avoid a difficult conversation. * **Requires Maintenance:** Keeping the backlog in good order is a significant activity. The Scrum guide suggests that a team might spend up to 10% of its time on backlog refinement activities. This is not a mandate to spend that much time, but it is an acknowledgment that this work—breaking down epics, detailing stories, re-prioritizing, and estimating—is a crucial and time-consuming part of the process. The product backlog can be managed using various tools, from specialized software like Jira or Trello, to simpler tools like a spreadsheet, or even a text file for smaller projects. The tool is less important than the principles behind its management. ### Structure of a Backlog Item A fully refined item in the product backlog, typically a user story ready for a sprint, will contain a wealth of information to guide the development team. This includes: * **Title and User Story:** The standard "As a..., I want..., so that..." description. * **Acceptance Criteria:** The specific, testable conditions for completion. * **Definition of Done (DoD) Application:** A note on how the team's universal DoD checklist applies to this specific story. * **Priority:** Its rank in the overall backlog. * **Estimate:** The size of the story in story points. * **Detailed Description:** Any additional notes, mockups, or technical considerations. * **Dependencies:** Any links to other stories or technical prerequisites. This comprehensive structure ensures that when the team pulls an item into a sprint, they have a shared and complete understanding of what needs to be built and how its success will be measured. ## A Practical Planning Example: User Authentication Module To see how these concepts come together in practice, let's walk through the process of planning a comprehensive user authentication and authorization module. **The High-Level Requirement:** "Implement a comprehensive user authentication and authorization module that includes user registration, login, password recovery, session management, and role-based access control. The module must ensure secure password storage using hashing, implement multi-factor authentication for added security, and allow administrators to assign roles with specific permissions to users." ### Step 1: Decomposing into Epics The first step is to break this large requirement into high-level, coherent capabilities, or Epics. We are looking for large, relatively independent chunks of functionality. Two logical epics emerge from this description: 1. **User Authentication:** This epic encompasses everything related to verifying a user's identity. It's about controlling *access to* the system. This would include creating an identity, managing passwords (creation, changing, recovery), the login process itself, and multi-factor authentication. This epic can stand on its own; a system can have authentication without complex authorization. 2. **User Authorization and Role Management:** This epic covers what a user is allowed to *do after* they have been authenticated and have gained access to the system. It's about managing rights and permissions. This would include creating roles (e.g., "Administrator," "Editor," "Viewer"), assigning users to those roles, and defining what actions or data each role can access. ### Step 2: Decomposing Epics into User Stories Next, we take each epic and break it down into smaller, more granular user stories. For the purposes of this exercise, we can list the core capabilities that would eventually be written in the full user story format. **User Stories for the "User Authentication" Epic:** * User Registration * User Login * Secure Password Storage (using hashing) * Password Recovery * Session Management * Multi-Factor Authentication (MFA) **User Stories for the "User Authorization" Epic:** * Role Creation and Management * Permission Assignment to Roles * User Role Assignment * Access Control Enforcement (based on role) ### Step 3: Decomposing a User Story into Tasks Finally, to prepare a user story for development, it is broken down into concrete technical tasks. Let's take the "User Registration" user story. The full story might be: "As a new visitor, I want to register for an account so that I can access the system's features." This story would then be decomposed into a list of tasks for the development team: * **Task:** Design the user registration UI form. * **Task:** Implement the front-end registration form with input fields (e.g., username, email, password). * **Task:** Implement client-side form validation (e.g., check for valid email format, password strength). * **Task:** Create the back-end endpoint to receive registration data. * **Task:** Implement server-side validation of the submitted data. * **Task:** Implement secure password hashing and salting before storing the user record in the database. * **Task:** Create unit tests for the registration logic. * **Task:** Create integration tests for the full registration flow. This final level of decomposition provides the development team with a clear, actionable plan for implementing the user story. ## The Potentially Shippable Increment and the Definition of Done A core goal of each sprint is to produce a **Potentially Shippable Increment** of the product. This means that the sum of the work completed during the sprint should result in a version of the product that is coherent, tested, integrated, and could, in theory, be released to customers. The emphasis is on delivering usable value, not just a collection of disconnected components. The lecture provides a powerful analogy to illustrate this. One approach to building a car is to deliver one wheel, then a chassis, then the body, and finally the complete car. In this model, the customer receives no value until the very end. The alternative, and preferred, Agile approach is to deliver a skateboard, then a scooter, then a bicycle, and finally the car. Each delivery, while not the final product, provides the customer with a usable form of transportation. The goal is to deliver functional increments in a logical order that maximizes their usefulness to the client. For example, building a sophisticated reporting feature is useless if the system has no way to collect the data for the reports. It would be more valuable to first deliver the data collection capability, even with a simple data export to a spreadsheet, and then build the full reporting feature on top of that. ### The Definition of Done (DoD) To ensure that every product increment is of high quality and truly "done," teams use a **Definition of Done (DoD)**. The DoD is a formal, shared checklist of all the quality-related activities that must be completed for any piece of work (like a user story) to be considered finished. It is a team-level agreement that creates a common understanding of quality and completeness. The DoD is universally applicable to all user stories; it is not created on a per-story basis. An example of a team's Definition of Done might include the following items: * **Code is peer-reviewed or pair-programmed:** This ensures that more than one person has examined the code for quality and correctness. Evidence of this, such as review comments, should be recorded. * **Unit test code coverage is at a minimum of 70%:** This ensures a baseline level of automated testing for the new code. * **All unit tests pass:** The new code must not break existing functionality. * **Acceptance tests are automated:** This facilitates regression testing and ensures that the feature can be easily re-verified in the future. * **Integration tests for affected areas are conducted and passed:** This verifies that the new component works correctly with other parts of the system. * **A usability review has been completed:** This ensures that any new user interface is consistent and user-friendly. * **The feature is tested on target platforms (e.g., iPhone 9-16):** This confirms compatibility with required devices or environments. ### DoD vs. Acceptance Criteria It is essential to distinguish between the Definition of Done and Acceptance Criteria: * **Acceptance Criteria (AC):** Are specific to a single user story. They focus on *functionality* and answer the question, "Did we build the right thing?" * **Definition of Done (DoD):** Is universal to all user stories. It focuses on *quality* and answers the question, "Did we build the thing right?" A user story is only truly complete when it meets all of its specific Acceptance Criteria AND all the items on the team's universal Definition of Done. ### Levels of the Definition of Done The DoD can exist at multiple levels. While the most common level is for a **Product Backlog Item** (a user story), there can also be a DoD for a **Sprint** and for a **Release**. * **Story DoD:** The checklist applied to each individual story (as described above). * **Sprint DoD:** A checklist of activities that must be completed for the entire sprint to be considered done. An example might be, "The demo system for the sprint review has been deployed to a publicly accessible server." This is an activity that only makes sense at the sprint level, not for each individual story. * **Release DoD:** A checklist for a major release, which might include broader activities like performance testing, security audits, or the creation of marketing materials. This layered approach ensures that quality is considered at every stage of the development process, from the smallest task to the final product release. ## Introduction to Agile Estimation: Story Points and Velocity To effectively plan a sprint, the team needs a way to estimate the amount of work they can realistically accomplish. In Agile, this is typically done not with hours and days, but with two key concepts: **Story Points** and **Velocity**. ### Story Points: A Relative Measure of Size **Story Points** are a unit of measure used to express a relative estimate of the overall effort required to fully implement a product backlog item. The key word here is *relative*. Story points are not an absolute measure like hours or days. Instead, they are a way to compare the size of user stories to one another. The effort being estimated includes everything involved in getting the story to "done": the complexity of the work, the amount of work to be performed, and any risk or uncertainty involved. Teams often use a modified Fibonacci sequence (e.g., 1, 2, 3, 5, 8, 13, ...) for story points to reflect the increasing uncertainty that comes with larger items. A story estimated at 2 points is considered roughly twice the effort of a 1-point story. A story estimated at 8 points is significantly larger than a 5-point story. This relative sizing is often easier and more accurate for teams to agree on than trying to predict exact hours. ### Velocity: A Measure of Team Productivity **Velocity** is the measure of the amount of work a team can tackle during a single sprint. It is calculated by looking at the team's past performance. If a team completes 20 story points in their first sprint, 22 in their second, and 18 in their third, their average velocity is 20 story points per sprint. Velocity is a measure of a specific team's productivity over time; it is not a measure of an individual's performance and should not be used to compare different teams. By combining these two concepts, a team can effectively plan its sprints. If the team knows its average velocity is 20 story points, they can look at the prioritized product backlog and pull in a set of user stories whose point estimates add up to approximately 20. This empirical, data-driven approach allows for more predictable and sustainable planning, enabling the team to consistently deliver value sprint after sprint.