You can build the best piece of software ever written, but if no one understands what it can do for them, its chances of being widely used are slim. Great user stories will crystalize for people what your product can do to make their lives easier or better. At NerdCloud, all we need is a good user story. We take these and turn them into products.
Users come first
You need to gain an understanding of the actual users of your product. Creating a user persona is an excellent way to get in touch with their expectations. What problems are they trying to solve? Thinking like a user will help you see your product from their perspective. You will gain insight into how they see its functionality, their needs, and the expected value they're looking for.
Keep it simple
User stories need to be high-level but also accurate and straightforward. Avoid using buzzwords, jargon and acronyms. Using simple language is the best way to get a user story across so that team members and other stakeholders understand user needs.
If a backlog of user stories describes your product, there is no reason to be bound by constraints such as budget, time, feasibility, or cost. There is little cost in allowing some of your most wild user stories to enter the backlog. However, the value of allowing some of your most expansive thinking into the backlog is enormous.
An epic is your big sketchy story. They typically describe large pieces of functionality that are broken down into smaller stories over time. It is like breaking down an engine into its moving parts. Epics are a fantastic tool for organizing your stories and keeping a clear view of the big picture.
Keep adding stories
As you get new ideas and develop new ways users will interact with your product, it is good to keep adding new user stories to your backlog.
It is essential that you can group and prioritize new stories according to the value of each story for the user and your business. This will also stop you from being overwhelmed by a huge number of stories and keep development on track. The difficulty, cost, feasibility, and effort required are also factors to consider when prioritizing stories. Cross dependencies in the stories can also force the order of entries. It is important not to discard stories that are not a priority. Hanging on to them means you can use them down the track as your product develops.
You still need specs.
Having a set of great user stories is a wonderful place to start, but they are just the beginning of the process. Your team will need to outline how the stories will come to fruition from a technical point of view. Linking stories to documentation that shows technical details from a software engineering perspective is a great entry point for more detailed technical specs.
How your product operates in the real world will measure its success or otherwise. Just getting to it works as it should or works according to the specs isn't enough. Actual user feedback, where you learn how happy and engaged your users are, will be the test for long-term results. Working according to user stories is fine for development, but you should be refining according to real-world results.
User stories are a great way to define your product and what you hope to achieve. They are brilliant at capturing your ideas and being the bridge to product development.