User stories are a awesome method for expressing stakeholder requirements, for example those of the product owner. They enable requirements to be described in simple and understandable dialogue. When a customer or product owner initiates a project – or has desire to build some new application feature, there are various elements that need to be examined…
Now user stories are by no means the be and end of all types of requirements gathering and writing. Hence it is important that they are used in the correct way to ensure they add value to the overall project. Should user stories be used to describe implicit technical requirements for in depth explanations for how a feature should be implemented, well not really. The primary goal of user stories should be for expressing stakeholder requirements. Solution (either functional or technical), transition requirements documents can all be used to describe the detail of how user stories may be implemented.
User stories are typically written from the perspective of a specific role, with a statement of a desired outcome and any related benefit/value for this requirement, see a typical statement below:
As a [ROLE], I want to [REQUIREMENT] so that [VALUE or BENEFIT]
A user story should not be viewed as a requirement in the traditional sense, but a trigger for a conversation(s) between developers and stakeholders so that they can identify and specify the detail of what is required to fulfil a requirement. You cannot simply provide you development team a bunch of user stories and hope this is all they will need to complete the work.
The goal of Agile based development is certainly not to avoid documentation and specifications, but to simply focus on the most immediate requirements, so that a team can focus on adding and delivering value where it matters most in ongoing release iteration cycle. Passing fads exist in both the business and technical world, it is not about… oh this feature/technology will be really cool to have… the question is, will this add measurable value/benefit to our end product? Of course it is great to do the “cool” things – but you must first be sure your priorities and focus meet your most important goals. You must always ask yourself – what value/benefit is this work/change adding?
Next I will look at the key points which I think make a good user story!