Try Storyboard That Free For 14 Days!
User Stories and Agile Development
A core tenet of modern development processes is Agile Development. Agile Development stresses using small bite sized user stories to define what a system does from a user perspective, not a technical one. A user cares if a product is fast, easy to use and solves their problem. They do not care if it follows a 3-tier architecture, has Mongo DB or if it uses Rails or Asp.net.
User stories:
- Are easy to understand by everyone and anyone can participate
- Work iteratively and can and should be changed often and amended
- Align developers, users, and business specialist around common goals and expectations
- Are a lot easier to read than 400 page requirement docs
Storyboard That provides an ideal platform to create user stories to spark conversation
and is much more fun than just reading text.
Epic
An “Epic” is a very large story that will later be broken down into many smaller
user stories. Starting with an Epic gets everyone aligned on the same high level
vision. If it does not make sense to do an Epic, any supporting work is also going
to be a waste of effort. This is a very top down approach to project management.
In our story creating a customer care tool, it is very clear what our long term vision is and what success should look like. A good Epic should include:
- Setting or Context
- Actors or Users
- Goals and Objectives
- Activities and Events
Create a Storyboard
Defining our users
When designing software, it is important to have a good vision of what the users
will be like. This is not to say every user will match exactly, or that there is only
one type of user. By thinking about users first, it prevents creating a product that
is something for everyone and useful to no one.
Creating a Story
To break down our Epic, we start with the two stories below: looking up a user and re-ordering a product.
When you review the stories, notice how there is no technical information.
The users do not care as long as it performs these tasks. Also notice the UX is incredibly generic at this
point to not stifle innovation or force a path. In general, stories should be:
- Small - Under 10 days work
- Valuable – Once completed they should deliver something useable
- Estimable – Able to create a ballpark estimate of how much effort
Looking Up an Order
Performing a Reorder
Create a Storyboard
Conversation
These stories should invite conversation. Are these the right stories to match our Epic? What other stories should be created? It is perfectly reasonable (in fact encouraged) to create many stories . Some will never be used, but it is important to see what paths they take you down. This will help flush out additional requirements and influence testing (below).
Planning for Testing
The stories should also invoke a real conversation about how the software should
be tested and what business rules need to be explicitly defined.
- How fast does a lookup need to be?
- Is there a time limit on re-orders?
- What should the system do if it is the second re-order? Fifth?
- What tests and follow up questions would you have?
Further Reading
Storyboard That provides a powerful solution to creating great user stories, but
it is not meant to be a one stop shop for educating on project management frameworks.
Below are some of our favroite books.
Create a Storyboard
