The Acceptance Criteria in Scrum is a list of conditions that a user story must meet to be considered 'done'. It explains the functionality, behavior, and performance that the team should achieve. It creates clarity about what is expected from the implementation of a user story. They are a powerful tool for creating a shared understanding between the team and stakeholders, reducing the back and forth communication.

The INVEST Principle is an acronym that encompasses characteristics of good user stories in Scrum. This includes Independent, Negotiable, Valuable, Estimable, Small, and Testable. Following the INVEST principle helps in creating high-quality user stories that are easier to comprehend, prioritize, and complete within a sprint.

The 3C's refer to Card, Conversation, Confirmation. The 'Card' is the written user story, 'Conversation' involves discussion about the user story between team members and stakeholders, and 'Confirmation' involves acceptance tests and the definition of done. This methodology drives successful implementation of user stories by fostering necessary conversations and ensuring a shared understanding before work begins.

The User Story Role-Feature-Reason Template is a standard representation of user stories. It arranges a user story in the order of 'As a <type of user>, I want <some goal> so that <some reason>'. This layout helps to place the customer at the center of the conversation. This format helps in understanding the essence of the user story and maintains its simplicity, clarity, and user-oriented approach. The 'role' helps in identifying the user or the system that will interact with the intended feature. 'Feature' is the functionality or the benefit that the user gets from the product. 'Reason' indicates the value or the outcome of the feature.

User Story Mapping arranges user stories on a two-dimensional grid aligned along a timeline of activities, which helps to create a clearer picture of the product functionality and its usage. It offers a more holistic view of the product being developed and allows the team members to understand the bigger picture of what they are trying to achieve. This map helps the team to prioritize the work and make decisions based on the complete image of the product and the user's journey. It's especially useful in planning releases and making sure that the most valuable functionality is delivered first.

Splitting User Stories is the process of breaking down a large user story into smaller, manageable units. The goal of splitting is to make the stories small enough to estimate, yet large enough to provide value when completed. A common technique is to split stories vertically encompassing all system layers and components, as this ensures that each user story remains an independent piece of business functionality from the user's perspective. The benefit of splitting user stories is that it aids the development team in understanding and estimating complexity and implementation time more accurately, and it reduces the overall risk associated to any single unit of work.

Epics and Themes are ways to organize User Stories into larger categories. "Epics" are big User Stories that are too large to be completed in one sprint and hence need to be broken down further. Whereas, "Themes" are groups of related user stories. So, if several user stories together contribute to realize a business goal, they can be categorized as a theme. Both Epics and Themes are beneficial in managing large products, as they offer the possibility to organize the user stories at a higher level by reducing the complexity and improving the ability to plan ahead.

Non-Functional Requirements (NFRs) in user stories refer to the aspects of the system that do not perform a specific task but support the system to operate effectively. These could include performance, security, usability, compatibility standards, etc. Expressing non-functional requirements as user stories can be challenging because they often are system-wide and not tied to a specific feature or functionality. However, incorporating them into User Stories help define the 'definition of done' and ensure these elements are considered during product development. It also assists the team in focusing on the overall quality, reliability, and efficiency of the system.

The lifecycle of a User Story in Scrum begins with its creation and ends with its closure which often involves several iterations. Initially, the Product Owner creates a coarse-grained User Story. As the team begins to work on it, they break it down into finer detail. Then, the Development Team estimates the story and it is placed into the Product Backlog. As part of a Sprint, the team then works to complete the story - writing the code, testing it, and then finally reviewing it within the team. Once the Story meets its definition of done, it is closed. The lifecycle of User Story is crucial for understanding the flow and evolution of work within a Scrum team.

Story Points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we assign are unimportant. What matters are the relative values. A story that is assigned a 2 should be twice as much as work as a story that is assigned a 1. It should also be two-thirds of the work of a story that is estimated 3 story points. It is a way to estimate the complexity, risk and repetition of a task.

Burn Down Chart is a graphic representation that shows the amount of work left to do versus time. In terms of User Story, this chart can help monitor the progress of completion of the User Story over the course of the Sprint. It assists scrum teams in predicting when the work will be completed. An upward bend in the chart indicates a problem and the team might not be able to complete the work by the expected time.

User Story prioritization is an essential activity in Scrum. Without prioritization, everything seems important and no decisions get made. It is the process by which you determine which User Stories should be taken up first in the Sprint. Techniques like MoSCoW (Must have, Should have, Could have and Won't have), Value vs. Effort, RICE(Reach, Impact, Confidence, and Effort) Framework, etc., can be used. The aim here is to deliver maximum value to the customer at the earliest with effective usage of resources.