Scrum Documents
Hy every one, i am confused about documentation in Agile as below
we try to implement Scrum in our company, the problem we faced is our traditional thinking which always requires physical document, My manager always asking me about Business Requirements Specification (BRS) and Software Requirements Specification(SRS)
is it a valid habit to writing user stories and their acceptance criteria as an alternative of (BRS and SRS) in a single document?
if it is yes, can you supply me with any template?
we use TFS project management, any suggestion about the problem
thanks.
What is the added value for the stakeholders in these documents? Can they agree with you to do so in a single document? Not sure what is common for these kind or practices as I've never experienced similiar situations, but every environment is unique..
we try to implement Scrum in our company, the problem we faced is our traditional thinking
What are senior management doing to change traditional thinking so Scrum can be implemented, and what contact do they have with Scrum Masters, coaches, and teams?
My manager always asking me about Business Requirements Specification (BRS) and Software Requirements Specification(SRS)
BRS = Product Backlog Items of all sizes. SRS = Product Backlog Items of all sizes.
Scrum is based on building things in increments, getting immediate feedback and then adjusting course based on that feedback. The old style was to define something in its entirety months (years) in advance and build it no matter how long it takes. That often lead to delivering the wrong thing at the wrong time thus the emergence of incremental delivery practices (i.e Agile, Scrum, Kanban, etc).
As @Ian and @Sander point out, if the company wants Scrum practiced, then the company needs to adjust to embrace the principles and practices. Suggest to your senior management that they allow the teams to progress on work as Scrum illustrates and support some changes in the way the company thinks/operates. Frame is to them as an experiment and place a time-box (2 months is my recommendation for the first iteration and adjust to 1 month after that) at which there will be a "review/retro" on the work in order to provide feedback on whether the practice is delivering the value that they expected. Treat that practice in the same manner you would a Sprint. That will also help them start to appreciate the iterative nature of Scrum.