User Stories & Tasks

BloomTech Labs - User Stories & Breaking Down Stories into Tasks

Introduction

The Agile framework has brought about a definite cultural shift in the software development world, away from extensive planning and iterative and lean execution. However, one thing that has not changed is that everyone still expects estimations of when developers will deliver software features and how long a project will take to complete. Task planning and estimates are complex, perhaps enough to consider them as both science and art. It can feel like an intimidating, daunting task for developers.

When it comes to breaking down Agile user stories into tasks and estimating their level of effort, there are good enough "science,” or at least proven practices.

User Story

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, 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.

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.

User stories are a few sentences in simple language that outline the desired outcome. They don't go into detail. Requirements are added later, once agreed upon by the team.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, 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.

User Story Format

• 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.

Breaking User Stories into Tasks

One thing that needs to be established right away is the fact that this is a team effort. While the product owner is 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 entailed.

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**_.