Coding as a Craft 2.0
  • Introduction
  • Week 1 - Programming Basics - Ruby
    • Understanding the problem statement
    • User stories
    • Pair programming
    • The ATM challenge
      • Step 1 - Setting the stage
      • Step 2 - The core functionality
      • Step 3 - Interacting with objects
      • Step 4 - Refactoring
      • Step 5 - Testing the sad path
      • Step 6 - Cash is King
      • Step 7 - The Account
      • Step 8 - The Person
      • Step 9 - Making it all work together
    • Library Challenge
      • Important Topics
    • Extras
  • Week 2 -Programming Basics - JavaScript
  • Week 3 - TypeScript and Angular
  • Week 4 - Ruby on Rails Basics
  • Week 5 - Working With Legacy Code
  • Week 6 - Midcourse Project
  • Week 7 - Going Mobile
  • Week 8 & 9 - Advanced SaaS Applications
  • Week 10 - Expose and Consume API's
  • Configuring RSpec
Powered by GitBook
On this page
  • What are the benefits of user stories
  • How do we write user stories?
  • Examples of user stories
  • Some final words on user stories
  1. Week 1 - Programming Basics - Ruby

User stories

User stories are small stories to describe the users of out app or program and what they want.

When working in software development we want to follow Agile values and principles, and the user stories help us to do just that. There are three Agile principles user stories that we need to keep in mind when we are writing user stories:

  • Working software is the primary measure of progress

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

  • Simplicity - the art of maximizing the amount of work not done - is essential

What are the benefits of user stories

There are a number of benefits of working with user stories

  • They clearly explain the business value of the feature

  • They make you stay in scope

  • They give you the ability to prioritize the features

  • They help you and your team to organize your work

How do we write user stories?

The stories should focus on the

Who we are building for

What we are building

Why we are building

The format for the user story is the following:

As a <stakeholder>            
In order to <requirement>            
I want <result>

Examples of user stories

You have probably seen some user stories in the prep course, these are two examples from the fizzbuzz challenge

As a programmer            
So that the game can be played according to the rules            
I want a normal number to return that number
As a programmer            
So that the game can be played according to the rules            
I want a number divisible by three to return 'fizz'

And here are two other examples

As a user            
In order to get product updates through email            
I want to add my email to my profile page
As a User            
In order to keep my password safe            
I want to be able to change my password

The first line is telling us who the stakeholder is, it could be the user, the programmer, the admin and so on. The second line is giving us the requirement of the story, why should we implement the story. The third line is giving us the result or the output we expect.

Some final words on user stories

From now on you will need user stories for all functionality you want to implement, you will either get some stories provided or you need to write your own. Having user stories is like planning ahead, they also give you small bite size chunks to work with rather than trying to wrap your mind around too much at the same time.

PreviousUnderstanding the problem statementNextPair programming

Last updated 7 years ago