Depending on how well a company implements agile, developers develop (heh) an opinion of whether they like it or not.
There are a lot of ways you can start using the agile process and not all of them are great. But there are certain components of agile, like user stories, that are just incredibly useful.
Learning how user stories are created when the agile process is applied correctly has changed the way I think about development. Even if the place I work at doesn’t have any type of agile process in place, I always try to bring user stories. Here are a few ways user stories have made my development process better.
They keep me focused on the user
Writing a user story is not the same as writing a task list. Thankfully, a product owner or someone else closer to the business side will usually create the initial user stories. They have heard directly from the users they are targeting, so they are telling you exactly what a user expects.
This crucial part gets lost when developers are going through writing a task list. User stories give important context to those tasks that let me know what should happen for the user when I complete those tasks. Being user-focused is an invaluable skill as a web developer because all of the code you write will eventually face some user you don’t know.
By thinking of the user while I’m writing the code, I come up with more test scenarios than I would ever think of from a task list. Task lists are great, but they should only come after user stories have been written. When you can tie a task to a story, you get to see the real impact that it will have on user experience.
They help me figure out how I should set up permissions
Most of the applications I have worked with involve different user permissions. Some users have admin rights and others have read-only rights to specific parts of the application. Without user stories, it’s more difficult to figure out what, when, and how I should show things to different users.
The beauty of user stories is that you can write them from different user perspectives called personas. So you can have a persona for admin users, read-only users, restricted access users, and all the other kind of users that will interact with your application. Most user stories are written in this format: As a [user persona], I [want to], [so that]. This format allows developers to use multiple personas to figure out how to complete the same tasks for different users.
They setup the framework you need to put yourself in the shoes of multiple users easily. Most user stories are created from conversations so you’ll be able to go talk to another developer or a product manager and ask more questions about what a certain type of user should see or be able to do.
They keep me and my team on the same page
When you and three other developers are looking at the same task list without user stories, it can be easy to forget why we are doing a task in the first place. The invaluable context that comes from user stories keeps this from happening. When the tasks are a break-down of a user story, everyone can see why they are doing things.
Many times the “why” behind a task gets lost and developer teams get rid of them. Then a user tries to do something and everyone remembers why that task was there. User stories help you avoid that. There’s never a question of “why” when the answer is a little sentence explaining what the user needs to do.
This will save you a lot time trying to sift through all of the interpretations each developer has and it’ll save you brainpower from constantly trying to remember why you all are doing this stuff in the first place.
They are easier to understand than a requirements document
My favorite part about user stories is that they don’t have any jargon. It’s just like a user walked up to you and told you what they want to do and what it will accomplish. That’s why easier to handle than a 10+ page document where there is so much jargon that not even the person who wrote it can understand. User stories are informal sentences that describe something a user wants to do.
Then it’s up to the development team how they want to break that sentence down into technical jargon. User stories might not be able to fully replace requirements documents, but they definitely make more sense of them. When you need to see the reasoning behind all the jargon, user stories help a lot.
They keep me entertained
My sense of humor has been… updated since I started web development. You would be surprised by what can sneak into user stories or the crazy expectations users have. You don’t find them every day, but user stories can carry their own sense of entertainment. Sometimes developers go down rabbit holes and you end up with some outrageous user stories that never leave the room.
It’s not a real function of user stories, but it helps the day go by a little faster. You can even get creative with them within your team. It makes the sprint feel a little easier and it makes the developer group laugh. Why not be entertained?
User stories really should be a big part of any agile process because they define the exact thing you need, the things that users are going to expect in the next release. Talking through what a user wants to do and why they want to do it will bring out potential issues before they get to the user. It also gives you and your co-workers a literal reason to do the work you have been assigned.
How do you feel about user stories? I think they’re pretty great for how simple they are. Have you seen any ridiculous user stories before?
Hey! You should follow me on Twitter because reasons: https://twitter.com/FlippedCoding