A user story is an informal description of one or more features of a software system. User stories are written from the perspective of an end user or user of a system. They describe the type of user, what they want and why. Each user story is aimed at achieving a specific goal or the desired output of the user. They help to create a simplified description of a requirement.

Acceptance criteria are the conditions that a software product must satisfy to be accepted by a user, a customer, or in the case of system level functionality, the consuming system. They are unique to each User Story and define the boundaries or scope of the story. Without it, a story can be interpreted in various ways, leading to misunderstandings and inaccuracies during development. Clear and precise acceptance criteria helps development teams to understand what needs to be done.

Definition of Done indicates the exit-criteria to determine whether a product backlog item is complete. In many cases, it includes items like functionality is implemented, code is reviewed and well-commented, all tests pass, product is deployable, etc. The Definition of Done creates transparency and improves team collaboration by ensuring that everyone understands exactly when a task is complete.

A product backlog comprises an ordered list of the features and requirements to implement in a product. It's created and managed by the product owner, and it's a dynamic artifact in Agile methodology, which means that items (user stories, in this case) can be added, modified, or removed based on business or market requirements. Items in backlog are prioritized based on their business value, and the most valuable items are developed first.

Splitting user stories means breaking down a user story into smaller pieces that still hold value and are testable and demonstrable. The reason for splitting a user story can be manifold: the story is too big (an epic), it's difficult to estimate, it involves too many unknowns, etc. The aim of splitting is to create pieces that can be developed, tested, completed, and shipped independently.

INVEST is an acronym that embodies the key principles of writing good user stories. It stands for Independent, Negotiable, Valuable, Estimable, Sized Appropriately, and Testable. A user story must be 'Independent' to reduce entanglement with other stories, promoting flexibility. It should be 'Negotiable', not a contract, leaving room for collaboration. 'Valuable' indicates that it must provide value to the customer. It needs to be 'Estimable' so that teams can understand the effort required. If it is too large to estimate, it's not 'Sized Appropriately' and might need to be split into smaller stories. Finally, it must be 'Testable', meaning that criteria should exist by which the story's completion can be verified.

Story Mapping is a visualization exercise that helps teams understand the user's journey through a product. The map is organized into horizontal rows. The top row is called the 'backbone', describing the user's overall journey. The rows below create a skeleton filled with detailed user stories, each corresponding to a part of the user's journey. These stories are mapped in the sequence in which the end-user would experience them. This helps to identify gaps, dependencies, and helps prioritize the implementation of stories.

Iteration Planning is a process where the team plans and agrees on the stories, or chunks of a larger task, that will be delivered in the upcoming iteration. Each user story within the iteration is estimated and given a priority. The overall goal of iteration planning is to match the team's velocity with a realistic workload, and ensure that the most important features are being worked on first.

A persona in Agile development refers to a fictional character created to represent a user type that might use a site, brand, or product in a similar way. Personas are extremely useful in helping to guide decisions about product features, navigation, interactions, and visual design. By designing for the needs of diverse users, personas prevent the languishing of possessing a too narrow or a too general focus on users.

Scenarios in Agile are simple, clear, narrative descriptions of user actions towards achieving a specific goal. It puts the persona into context and shows how they interact with a product to complete a task. Scenarios are written from the user's perspective and often include preconditions, the specific task or goal, and the post-conditions. They offer a more detailed description of a user story and a step by step guide of how a feature should work.