Stories are an excellent way to capture end-user or customer requirements and other work that must be done to complete a project. Stories are part of Agile, but you can use them with any project-management methodology.
Below are different types of stories you can use in your project.
An Analysis* Story describes research that needs to be done. If any member of your team needs to go find out something, that can be documented as an Analysis story. Analysis stories can be requirements gathering or clarification, studies, interviews, root-cause analyses, getting information and advice from a subject-matter expert–anything along those lines. An analysis story has a question to be answered. It is “done” when the answer is known. Thus, analysis stories generally only have one "done," or exit criterion. Analysis stories lead to other stories.
Examples of Analysis Stories
As the Product Owner, I need to clarify why the customer wants the search functionality to only search web pages and not files so that we can make sure what the actual search needs are.
As an interactive designer, I need to research how best to create a liquid web page layout that scales to all device sizes.
A Business Capability* Story identifies a capability that needs to be acquired or developed before the team can complete the feature. For example, a service that must be contracted for, a process that needs to be in place, documentation that must be written for the project or service team, needed equipment, needed training.
A Deployment* Story describes how a deliverable is introduced to the user and supported.
Environment* Stories identify physical, logistical, or virtual configurations that must be established before the a deliverable can be developed and deployed.
User Stories identify what users require, how they experience and interact with the deliverable.
This way to learn more about User Stories and see examples.
An Epic is a large story that needs to be unfolded into smaller, "right-sized" stories that can be accomplished within a given time frame. Agile teams right-size stories so that they can be completed within a Sprint (also called an Iteration).
Problem, Bug, Defect
Problems inevitably arise during projects and must be addressed. Software teams identify these as Bugs. Lean-Agile teams frequently call them Defects. But any problem can be documented as a story, with tasks to fix the problem and exit criteria stipulating that the problem is fixed and your team** has verified that it is fixed.
*Analysis, Business Capability, Environment, and Deployment Stories are sometimes called Foundation Stories.
**Don't forget that your team includes your customer!