In traditional project management, a detailed requirements specification document is created, usually by a Business Analyst, which is basically a one stop shop for documenting all the project requirements. The Business Analyst works with all stakeholders making sure that their requirements are being documented. This requirements specifications document is then reviewed by project stakeholders and baselined. Once baselined, it is then handed over to Engineering for development. In some cases, it goes to the designers for creating design document before Engineering can start development. Since this is typically a large document and changes so many hands, it is possible that a substantial amount of written requirements are lost in translation.
Agile asks the question, can there be a more ‘agile’ way of handling requirements instead of creating 300-page long specs document?
To think of it, a software is supposed to help people do things. If a user asks the team to build a feature, it’s because using that feature, they will be able to do something that they can’t do today. In Agile, the belief is that the most efficient way of building the right thing is to keep the user needs in mind throughout the development process.
A user story is a very short description of a specific thing that the users need.
User stories are usually written on index cards or sticky notes and not in a 200-page long user story document! Scrum teams organize all their work around user stories. This ensures that the user needs are kept front and center in their planning and prioritization process. This also ensures that the scrum teams focus on building what their users need and there are no surprises when the team demonstrates the user stories at the end of the sprint.
Usually, teams write user stories on note cards following a fill-in-the-blank format. Below is an example,
Since user stories are short and modular, they act as a reminder for the team to constantly confirm that they’re building the right feature.
Check more articles on Agile
