> For the complete documentation index, see [llms.txt](https://bryan-guner.gitbook.io/my-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bryan-guner.gitbook.io/my-docs/lambda-labs/labs/user-stories.md). # User Stories ## User Stories ### What are User Stories? A **user story** is the smallest unit of work in an agile framework. It’s **an end goal expressed from the user’s perspective**. The user story is an informal, general explanation of a software feature written from the perspective of the end-user or stakeholder. Note that it's not a feature itself! The purpose of a user story is to articulate how a piece of work will deliver a particular value back to the stakeholder. Note that "stakeholders" don't have to be external end-users in the traditional sense. They can also be internal stakeholders or colleagues within your organization who depend on your team. A **stakeholder** is anyone who has a stake in the development of a product. User stories are a sentence or two in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team. ### User Story Formats * As a (**who** wants to accomplish something) * I want to (**what** they want to accomplish) * So that (**why/rationale** on what the user wants to accomplish) **Example:** As a ***user***, I want to ***log in using a username and password*** so that ***the system can authenticate my login.*** ### User Stories and Agile Development Stories fit neatly into agile frameworks like Scrum and Kanban. **Agile** is a development methodology that focuses on **responsiveness to change**—keeping the development process **lean** and focusing on keeping everybody **aligned**. You keep development cycles short, so you can get a **minimum viable product** (MVP) up and running quickly, and then **iterate** (repeat) during the next cycle based on what you learn from it. In Labs, we'll use an agile workflow that you'll be able to translate into a wide variety of work environments in the industry. In Agile, user stories are added to sprints and “burned down” throughout the sprint. **Kanban** teams pull user stories into their backlog and run them through their workflow. **Trello** is a form of Kanban to help your team manage their user stories and tasks. Thanks to stories, Kanban teams learn how to manage work-in-progress (WIP) and refine their workflows. ## Trello ### Trello and Kanban **Kanban** is a methodology that comes from Japanese manufacturing practices developed in the mid-20th century. Factories would use written cards handed from person to person to communicate the status of operations. These cards were a "lean" way to manage the creation of products that was highly responsive to the realities on the ground. In the same way as efficiently manufacturing cars, agile software development requires responsiveness to changing realities. Microsoft began developing an approach (that was soon iterated by many) to track progress on a "**Kanban board**"—a set of columns containing cards representing bits of work. The development team would move the cards along the board to different columns to represent their status. [**Trello (Links to an external site.)**](https://trello.com/home)\*\* \*\*is an implementation of a Kanban board system by the Australian software company [Atlassian (Links to an external site.)](https://www.atlassian.com). Trello lets a software development team track the progress of bits of work throughout the SDLC. ### Trello in Labs In Labs, you'll use Trello to track all the state of all development on your product. Here's a high-level overview of how we'll use Trello in Labs: And here's a look at the Trello **workflow** we'll use in Labs: {% embed url="" %} {% embed url="" %} ## Tasks ### Tasks A **task** is a granular unit of work that needs to get done to ship a user story. One thing that needs to be established right away is the fact that **this is a team effort**. While your team's Technical Project Managers are responsible for prioritizing the backlog and capturing requirements from the business and the users, the developers are really the ones best positioned to understand what in terms of technical capabilities must be developed, as well as the level of effort that will entail. ### Tips for Tasks There are a few important things to consider when breaking down user stories into tasks: * ***Keep tasks small, but not too small*****.** As a rule of thumb, a task should be something that can be done within a single day, but not in a few minutes' time either. * ***Keep tasks very precise in scope*****.** Don't create tasks with such vague statements as "Coding" or "Implementation" thinking that anyone can just refer to the parent user story for details. Write something more meaningful that also makes the scope very clear. For example: "Develop the login class." * Use the user story's ***acceptance criteria*** as a starting point, and its ***definition of done*** \*\*\*as a checklist. The acceptance criteria will help you determine what features need to be implemented, and the definition of done is a checklist for all user stories that can also help you determine if you're missing any tasks for the story to be ***done***. ### Breaking Down User Stories Into Tasks ## User Flows, Wireframes, and Styles ### User Flows and Wireframes Designers frequently use lean artifacts like user flows and wireframes to think about and communicate how users will interact with anapplication. #### User Flows A **user flow** is a diagram that shows how a user moves through an application to achieve a goal. #### Wireframes A **wireframe** is a basic blueprint of the layout, hierarchy, and components of a single screen or view. ### Styles **Styles** are anything that affects the feel or personality of an application. Styles can generally be boiled down to **shape, color, and type**.