Skip to main content

Scrum Documents

Last post 04:37 pm February 22, 2019 by Daniel Wilhite
3 replies
05:40 pm February 21, 2019

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.

 


12:38 pm February 22, 2019

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..


01:09 pm February 22, 2019

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?


04:37 pm February 22, 2019

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.