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.)** **is an implementation of a Kanban board system by the Australian software company Atlassian (Links to an external site.). 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:
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.
Last updated