Software which doesn’t works or which is full of bugs is of no value, whether you develop your code using waterfall or agile it doesn’t matter. One of the fundamental principles of agile world confirms this “Working software over comprehensive documentation”. Agile follows the principle of satisfying the customer through early and continuous delivery of valuable software. This fundamental guideline/principle itself emphasizes the importance of the quality. If I talk in scrum terms all the stakeholders are responsible of quality. The Product Owner creates the story, gets the necessary feedback from customers and discusses the acceptance criteria with the team. When the team starts working on these stories, all these quality/acceptance criteria are verified within the sprint (and after the sprint by the customer). Any deviation is noted at the earliest and necessary actions taken.
Traditionally user stories (or requirements) were written by Business analysts. They used to prepare big documents after months of study. It was a herculean task. I used to get such UI/Functional specification documents. I have fixed a lot of bugs because I missed few text in such 1000 + pages document. This is not the only interesting part. Some of the requirements were so weird that I often wondered why I am creating the features which no one is going to use. If I had the option I would have recommended a better option. If the BA’s misunderstood some requirements & customers failed to correct those few words in the epic requirement then we will have a nice situation. In the agile world the story is different. Product Owners are primarily responsible for user stories. But can anyone else also contribute? Yes. Definitely yes In actual environment many users write user stories. The first requirement may come from end user. The PO, tech architect, scrum master, BA’s... anyone can up