A Live Developer Journal

Researching user stories and brainstorming some for my fitness app.

The other day, I was looking around for a fitness app that was cute, empowering and tailorable. I wanted it to be easy to use and let me do a few of the things I had in mind. I couldn't find one that fit my needs. So I have decided to build it myself, which is one of my favourite things about being a developer.

At the same time, I want to use this app as an opportunity to get better at Test-driven development.

The recommended starting place for building a test-driven app is to start with a bunch of stories that tell you more about the system. More specifically, start with stories about your user, their needs and how they want to use the program. These kind of stories are known as user stories.

I don't know much about coming up with or writing good user stories. So I looked around for a couple of articles. The first one gave a few examples of user stories and I immediately knew they were not good examples. The examples given talked about what the system should do at an implementation level, rather than what the users needs are. There is more than one way to implement a user's need. Focusing on implementation details is restrictive, and eclipses the user and their needs. Hmm, perhaps I know more about them than I think.

After coming across a few more articles like this, I decided to look for articles written by trusted sources. This is a shame, because these articles are supposed to be written for beginners who may not be able to tell the difference between what makes a good user story or not. I searched for user story articles written by Kent Beck, who I didn't know actually invented the term in his Extreme Programming book which is what came up in the search results.

Instead of clicking through to the book page, I spotted another article on user stories written by Martin Fowler, who has worked closely with Kent Beck and has written some amazing content that I have read before. So that is the article I started with.

In Martin Fowler's article on User Stories, he says that user stories are chunks of desired behavior of a software system. He says that they are generally used to divide up large chunks of functionality into smaller pieces for planning purposes.

Formulating User Stories

According to Martin Fowler, he and Kent Beck prefer to write user stories on very small post-it notes on purpose to avoid capturing implementation details. We only flesh out their detail when they are ready to be developed. We use them to prioritize which elements of our software system should be developed first.

A technique mentioned for writing user stories is filling in the blanks in the following phrase:

As a ... I want ... So that

This way of phrasing the user story puts the user first, highlights their needs and a potential solution for meeting those needs.

Industrial Logic use a different template for creating user stories: Role, action and context (optional).

Principles behind a good user story

There is a helpful mneumonic which describes the characteristics of good user stories. This mneumonic was invented by Bill Wake: INVEST

Brainstorming user stories for my fitness app

As I am primarily building this app for myself, I will be the user of my system. However, instead of using 'I want to... so that', I'll use a different identity phrase to make it a bit more general. What categories can I fit into? Software engineer, beginner trainee, recreational athlete, professional woman, minimalist, etc, etc.

Of all of those categories, the 'professional woman', and 'beginner trainee' category stood out. Both of those names still don't feel right for this app though. I used the word 'professional' because I work full time and have been struggling to plan my fitness journey and meals etc. The 'beginner trainee' refers to the fact that I am not an experienced sportsperson. I don't want an app that uses a lot of jargon that is difficult to understand. Okay, I'll just use 'fitness newbie' for now.

Okay, that was a lot harder to do than I thought it would be. I keep thinking at an implementation detail level. I need to think about this more and try again, because the stories I have written above still feel a little 'wrong'.

It might help to think about some of the problems I am currently having and start from there:

As a fitness newbie with little time to herself, I want to calculate the calories and macros for custom meals easily, so that I can save time at the weekend.

As a nutrition newbie, I want to see the nutritional information for custom meals, so that I can save hours of meal planning at the weekend.

I like the bottom one better as it is less implementation-based. Still not sure though, will ask for feedback on twitter.