Implementing a process around user stories can take a lot of the stress out of software developers’ work. User stories provide a clear backlog of work, and simplify the software development process. We’d take our user stories process for granted, except that many software developers we interview who have worked elsewhere tell us something like “Wow, it must be nice to know what to do” when they hear about our process with user stories.
In this post, we’ll cover what user stories are, and how putting them to work can help you be disciplined instead of running a company or project by the seat of your pants.
What Are User Stories?
Essential for a smooth development process, user stories are the most atomic units of describable work that developers and “business” people alike can understand. User stories are the common language understood by both developers and non-developers. Developers ultimately write code to implement user stories.
We use the Gherkin format for writing user stories:
In order to <do something of value>
As a <user type>
I want to <perform some function>
User stories are added to the development backlog , which is a list, ordered by relative priority, of user stories. If a user story is on the backlog, it is on the development schedule. If a user story isn’t on the backlog then the developers will not write code implementing the user story.
Developers should write user stories in a consistent manner and so that all technical complexities are considered. Being thorough allows developers to assign accurate estimates to the user stories.
Estimating User Stories
Part of writing user stories is estimating the complexity of writing code to implement the story. This helps you plan development and design time, as well as budget costs for a given set of work.
User stories are assigned “point” estimates. Points describe the relative complexity of a story. For example: a 4-point story is probably twice as hard to implement as a 2-point story.
There are several point scales you can use to estimate the work around a user story:
Linear (0, 1, 2, 3)
Exponential (0, 1, 2, 4, 8)
Fibonacci (0, 1, 2, 3, 5, 8)
We use the exponential scale, but it’s up to your team to find out what works best for you.
The Lifecycle of a User Story
1. Not Started
Developers haven’t started work (coding, thinking, whatever) on the story. It’s free for any developer to take.
2. Started
A developer takes ownership of the story and has started architecting, writing tests and generating code to implement the story.
3. Finished
Code is written and checked into the repository for review by the technical lead and ultimately deployed to the staging server for review by product owner.
4. Delivered
The technical lead has approved the story and deployed it to the staging server for review by the product owner.
5. Accepted or Rejected
Accepted
The product owner has reviewed the story and declared that the story was built to his/her expectation.
Rejected
The story is not to the product owner’s expectation and is sent back to the developers. This is not a big deal; rejections happen all the time. The important thing is that the product owner approves all work before it gets deployed to production.
Accepted stories can then be scheduled to go to production. Developers own the Not Started to Delivered phases whereas the product owner owns the Accept/Reject phase.
Implementing user stories takes time initially, but saves you so much time and confusion down the road. How does your team implement user stories? Comment and join the conversation.
Taking a project's temperature also keeps our team on track, read how we do it.
__
