User Story driven application development

 

In this article I will explore how User Stories can be used to drive your application development.

I’ve been working on a big digital transformation project with a client for the last 18 months. One common theme that has been plaguing the team is;

• What is in-scope for this release, 
• What deliverables give the most value and; 
• Is the end-to-end process flow functioning as expected?

 

In large scale transformation projects often the above three issues can’t be avoided. However, User Stories (US) can help a development team stay focused, even when priorities are constantly changing. The reason for this is because the development team has a clear goal to build towards. The end goal should be easy to explain in layman’s terms. It should be in the same simple prose spoken to the top executive to the junior programmer. One way to measure the simplicity of your goals is to get the least experienced team member to explain what the team is trying to achieve.

 

An example User Story:

“As an existing customer I can withdraw cash from an ATM using my mobile phone”

 

A Business Analyst would delve deeper in their documentation to describe something like following:

• The user’s mobile phone must be payWave compatible.
• The user must enter their 4 digit PIN when prompted.
• Users can only use ATM’s with compatible payWave receivers.

 

The idea is that the Business Owners know what their clients are able to do and what the value is, so this can be related back to their business strategy. And also, the development team knows what functions they are building towards and importantly they can test it.

What are User Stories for?

Now we have an idea of what a User Story is and why it is a useful development tool. Let’s talk about where in the development process it can be used. The same User Story can be used for the following important milestones:

 

Requirements

A User Story can be used in dialog with Business Owners to talk about what requirements are necessary to deliver change and value. They are a good way to help articulate the solution to a problem. Often business owners are not tech savvy, so there is no point in discussing technical requirements with them. They won’t know what they are really agreeing to and it will make it harder to do User Acceptance Testing (UAT). Keep requirements in a language a Business Owner can understand. A good Business Analyst will be able to translate User Stories or requirements into functional requirements in consultation with the technical team members, later on.

 

Scope

Functionality

Having clear user behaviour and outcomes will make it easy for developers to know if the functions they are building will meet business objectives. For example, if it has been declared that feature A is out-of-scope for the current release, but it is required to deliver User Story 1, then a conversation can be had around why feature A is out-of-scope. And it’s priority can be more clearly defined.

 

Product demos

Being able to demonstrate the product to the Business Owners will go along way to keeping their confidence in the project and your team. You’d be surprised how often Business Teams forget exactly what they wanted. Sometimes this is because team members change or competing priorities influence the direction of the project.

 

Testing

All of the above components are important, but this I could argue is almost the most important. You won’t demonstrate or release your product, without testing it. Testers are the gatekeepers and often see things the development team cannot. So having User Stories for testing, in particular UAT will make it really clear what the application should be doing. 

Real World Example

Business Owner project statement

I want to create a mobile game, the general theme is a 2D endless runner with in-app purchases to create revenue and a community feature to help drive user engagement. It should run on all types of mobile phones and tablets. I want it to be aimed at a largely male audience between 15 and 40 years of age. The theme will be car and truck related.

 

User Stories

General App Use

1. As a player I want to be able to install the app in order to play it.
2. As a player I want to be able to start the game.

Revenue 

1. As a player I want to be able to make in-app purchases in order to progress through difficult levels.
2. As a player I want to be able to see my in-app purchases easily so I know what I do and don’t have.

User Engagement

1. As a player I want to be able to create an account in order to use the community feature.
2. As a player I want to be able to see my rank within the community feature to compare my status against other players.

 

Explanation

I kept this example simple, with one actor called “player”. I broke it down into three categories, ‘general’, ‘revenue’ and ‘engagement’. This helps business owners know which priority each US is targeting. From the Business Owner Statement we can break it down into 6 easily digestible US’s. As a development team we now have 6 core end-to-end flows to discuss, build and test. We can prioritise them, we can discuss dependencies between them and we can scope/descope them. As a Business Analyst or Project Manager there are now clear deliverables and product demo’s that can be shown to the Business Owner. 

 

Summary