We have all seen Agile enthusiasts embrace User Stories as a key method of identifying priority items and translating them into their development schedule.
We can see why.
User Stories, or feedback submitted by developers, partners, customers, managers or other stakeholders, gives you a clear view of how the product is performing at the user-level.
But are User Stories really that critical? We always start with our Requirements, meaning we already have a higher-level, more technical and more formal way of capturing information about the system. Won’t User Stories just cloud the process?
The truth is, while Requirements and User Stories are two different approaches, they are useful together, complementing each other and working in combination for better outcomes.
User Stories – Getting Everyone’s Input
Let’s begin with a quick overview of User Stories.
Any approach to project management should be open to soliciting and collecting User Stories, or people’s feedback on their user experiences.
User Stories are typically:
- Told from the user’s perspective
- Short and to the point
- Written in plain language
The stories should:
- Describe the capability they want
- Speak to the reason for the change and anticipated benefits
- Be delivered in whatever way the user wants – handwritten, email, sticky notes
When we think about User Stories coming at us in all forms – emails, sticky notes, emails and handwritten letters – it may feel like a messy process, but the truth is, with a properly organized workflow, User Stories can be integrated seamlessly and translated into work or testing items.
The Bridge: User Stories and Requirements
As you scope out your project management workflow, Requirements are your natural starting point. Requirements are your ultimate standard for functionality, performance and user experience.
As the project progresses, you will begin receiving User Stories, particularly if your people are accustomed to working in an Agile environment where User Stories play a central role.
The key is to remember how these different components fit together and complement each other in the overall plan. Both may be expanded by business models. They are both constrained by the same restrictions.
Specifically, there are some key areas where User Stories and Requirements can work together to enhance your implementation plan.
Reinforcing Your Base Element – Often you will find that a particular User Story is simply a re-statement of an individual’s perspective on your Requirements. There is a sense of reassurance here – embrace it! Move forward with the confidence that comes from knowing the requirements accurately reflect the real world experience of using the product.
Prioritizing Your Testing Phase – You may be tempted to take the straightforward approach by testing the User Story, and by addressing the user’s needs, declaring the matter finished. The truth is, the User Story is probably a reflection of one of your requirements, and while testing the User Story is helpful, a more effective and dependable method is to test the Requirements. Again, the User Story is a helpful indicator, and in conjunction with the requirements, your team will get a more complete picture of the system’s demands.
Integrating the End-User Perspective – Perhaps the most important contribution of User Stories is their ability to integrate the user’s perspective into the development protocol.
User Stories are a valuable complement to Requirements. They confirm your priorities, identify areas for additional work or testing, and most importantly, integrate the user’s perspective into the development team’s work plan.
To see a methodology for how User Stories fit within your overall implementation plan, consult our Whiteboard video.