(short on time? TL;DR)
What are User Stories?
User stories are basically the concept of user defined features. Users can be anyone including admins, departments, clients, and even the general public, all depending on who the feature benefits. The way you create a user story is through just typical regular conversation. Any time you’re talking about your product and some cool new idea comes up, try to describe it from the end user’s point of view and you’ve got a user story. For example, let’s say you’re building a website, and you talk about the user being able to sign up for a news letter (feature). The user story you would write to describe this would be written like “I want to be able to sign up for a news letter”. Now, because you might have multiple types of users, it’s helpful if you start by interjecting who you are when you want something. You also should interject why you want what you want, to help the designers think about different solutions. In the end the story might be, “I, the user, want to be able to sign up for a news letter, so I can get updates about the company.” (the user could be replaced by admin, end user, company, etc). This format boils down to “I, -role-, want to -goal-, so I can -reason-.”
Why do we care?
So now we know how to make stories, but why do we care? Let’s talk about remodeling your house.
Traditionally, you and a contractor would sit down and plan out everything you wanted to change. You would decide that you wanted certain things such as knocking down some walls, adding some new windows, maybe even getting a new pipe or electrical line, or both! After that planning session, the contractor would go out to the people who did the work, and provide them with the specific parts of the blueprints that they cared about. The window guy would get the requirements for windows, the plumber would get the plumbing requirements, the electrician the electrical requirements, etc. All of these guys would come into your house and build exactly what they were being paid for, as quickly as possible, and then leave. The benefits of this are pretty big. For one thing, it’s very efficient. Everyone is focused on their job and how to get it done quickly and efficiently, within budget. Another thing is you know you’re getting exactly what you asked for, and the price it will cost you. When this system is working perfectly, it’s really quite a nice system. Unfortunately, after you sign your contract and deliver your money, There is less communication between you and the contractor. They are focused on the job at hand. This can lead to you getting exactly what you asked for, which might not be exactly what you want.
*Note: This system can (and does) work when the contractor is really good at their job. A good contractor can (and has to) get it right on the first try, which makes them good. This is why contractors are striving to provide more accurate mock-ups, and simulate all of your options. It’s so they can get it absolutely right before starting, which allows this process to go very quickly after that.
Now let’s pretend that construction is a little different and you’re able to put in requests, but it’s up to the team of workers to figure out a solution. Instead of deciding everything, you would state problems that you have with the current setup, and new features you want. Some of these might sound like: “There isn’t enough room in the dining room for Thanksgiving dinner. I want to be able to seat 15 people instead of 8.” or “I want a double oven so I can bake 2 things at the same time.” Each of these statements can be translated into stories. Then the contractor takes these stories and goes to the team to come up with a plan. They’re going to apply their expertise with you in mind, because the whole point of the story is to solve a problem you have, or add a feature that you want. They’ll figure out the most effective way to solve your problem/add your feature. After they come up with a plan, the contractor might come back and pitch the idea(s) to you with a recommendation, or if you really trust him/her, you might just let them get on with the project. Regardless, eventually ideas will be green-lit, and the workers can start working on the task at hand. The difference here is they’re already all aware of how their results will affect you because they have been planning with you in mind from the start. This is a subtle difference on the surface, but if you look deeper, this makes all the difference.
Ok, but I don’t do Construction
That’s ok because this theory of user stories applies to any line of product creation, including web development. User stories make a huge difference in web development because everything you do is for the end user, and user stories help you focus on your end user. User stories challenge you to always ask “is this what is best for the user?”.
Hopefully this has peaked your interest and you want to know more. That’s great because there is a ton of content out there to help. Here’s some now:
Mountain Goat Software
User stories are goals/feature/solutions that are written the the format “I, -insert role (usually the user)-, want -insert goal-, so I can -insert reason-“. User stories help teams come up with a user focused solution and constantly challenge teams to re-evaluate their solutions with the user in mind. User stories help the process stay iterative instead of waterfall, resulting in a progressively better product whose development can respond to changing requirements. More information can be found here:
Mountain Goat Software