Every project starts with a Software requirement Specification (SRS) document, but somewhere in the middle a decision to adopt agile methods is made. So the question arises whether an SRS can serve as agile's product backlog? Let's find out. An SRS is a document with all the direct or indirect requirements of the system are listed. It generally has statements like "The system shall.."

Whereas product backlog serves two purposes: 1. It lists the work that is to be done and 2. It prioritizes the work to be done. It is different with the SRS in the sense that SRS only tells about what work which is to be done, not the priorities. So just for the sake of adopting agile, SRS should not be mixed with user stories, instead a product backlog should be created which will serve the purpose well. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/can-a-traditional-srs-be-converted-into-user-stories#

There is a misconception about agile model with teams across the world. They create an iterative waterfall model and call it agile. In a traditional waterfall development, analysis of the entire project is done first, followed by design for the entire project, followed by coding and testing. In iterative waterfall, the same approach is followed, but each story is treated as a mini project. They do the analysis for one story followed by design, coding, and testing. This is not agile. They confuse both the model because they thrive to build an agile model without exactly considering its meaning. The incorporation of user stories, or treating it as short placeholders for future conversations; each story becomes a mini-specification document. Ideally, in an agile model, all types of work would finish exactly at the same time, be it analysis, design, coding or testing. It is not always possible to achieve this, but it should become team's goal. To know more, read the article by Mike Cohn (founder of Mountain Goat Software), at: https://www.mountaingoatsoftware.com/blog/an-iterative-waterfall-isnt-agile