“cargo port crane” by Kyle Ryan on Unsplash

In software development, one of the hardest things to do well is knowing how to keep track of features that you need to ship, and when to ship them.

A common problem I faced prior to learning, and applying agile software management techniques, is that when there is a feature I am trying to tackle, I end up not knowing how much of a feature I need to build, or how much I have done without looking back at my code and going 'Ah! There was were I previously stopped at.'

In agile software development, a large piece of work / feature that can be broken into smaller chunks is known as an epic.

The smaller chunks within each epic are called user stories.

A real life example I could think of would be travelling between point A to B in say a car. We generally wouldn’t know the details in between A to B.

User stories would be how we actually plan get from A to B.

Celebrating Small Wins

It is often hard to estimate how long we will take when building software, there are too many decisions we need to make, and that can lead to overthinking or poor estimates.

To correct or reduce the risks involved in estimating, we use user stories to help better estimate a task we have at hand.

What are user stories?

User stories are, simply put, the smallest amount of work told from the perspective of the user. It follows a simple template;

`As a , I , so that `

These are usually written on post-it notes and used during planning and discussion. We use Pivotal Tracker at work, a tool which I highly recommend you use to help track your user stories.

User stories on Pivotal Tracker

Breaking it down

Let’s break this template down into smaller digestible bits.

`As a `

Here we are looking at the problem from a type of user (e.g. administrator / writer etc) or persona’s name (e.g. John).

`I `

Here we are describing our intention, not features we are using. Instead of `I use `, it is `I want to `

`so that `

And finally, this describes the desire to do something.

This shifts our mindset from purely building features, to actually understanding how a person using our product feels.

Why user stories and not to-dos?

While user stories and to-dos are similar, to-dos keep the team focused on checking things off, user stories on the other hand, keeps the team focused on looking at issues from a user’s point of view, and tackling the problems faced by the user instead.

Examples

How do we write one then? Using the above template, we can easily craft stories out. Let’s say we have a simple profile page, and want to add new features.

If we were to add a new feature in a application from an administrator’s perspective, here’s what we will get:

`As a admin, I want to see the users’ last sign in date, so that I can better track usage of the app`

Or from a user’s perspective:

`As John, I want to change my profile picture, so that my friends can recognise me better`

How do we estimate?

In addition to the template, we estimate the amount of effort, and difficulty level that we think we a user story might have using a measurement of points.

At work, we use the fibonacci sequence,`0, 1, 2, 3, 5, 8`, with 0 points being a simple task, and on the other end of the spectrum, 8 points, to indicate the user story is going to be relatively difficult or require a lot of effort.

For example, in the user story mentioned earlier,

`As a admin, I want to see the users’ last sign in date, so that I can better track usage of the app`

Someone who is experienced working with the application, may give the story 2 points, while a developer who is new to the application, might give the story 3 points.

These points are then calculated to measure the velocity of each iteration of a project, which can help to plan future iterations.

Summary

I personally love user stories, as it helps me to break down a huge problem into smaller, more manageable chunks which I can then prioritise accordingly.

Understanding how they work and utilising them correctly would be key to delivering great software. I would highly recommend you start by evaluating the next project you are working on, and break them down into smaller user stories.