Skip to main content

Requirements Documents

Last post 02:47 am November 2, 2016 by Nick Pranovich
7 replies
11:47 am October 13, 2016

Hi fellow Scrummers....
I have just come out of a meeting where I had suggested, in my role as a Scrum Master, that our development teams should NOT be required to read project requirement documents.
Now I know that there will be those lucky people out there who don't have this overhead to deal with, but we are moving through an Agile Transformation, and I'm trying to get the organisation to "buy-in" to the new process.
The project is quite a huge one, and there is at least one 65 page Requirements document that the PMs and other stakeholders are expecting developers and testers to read.
I have said that they shouldn't have to do this.....
What are the thoughts of any of you out there who may have had experience in this area before.

Thanks
Tony M
Leeds, UK


05:20 pm October 13, 2016

Hi Tony,

when we did it at my company, we just simple transformed the most important features described in the requirements document into user stories / backlog items in a two days workshop with the key stakeholders. Actually it worked pretty well. Of course we had the full support of the company management, which is not always the case.

Best regards,
Peter


05:22 pm October 13, 2016

> we are moving through an Agile Transformation

Do you have evidence for this, and if so where is the sponsorship for any change coming from? What steps are being taken to implement new roles and responsibilities and new funding models? Where is the Product Owner who can articulate value in terms that are better suited for incremental delivery?


05:45 pm October 13, 2016

Hi guys
Thanks for your replies.
Our PO is new to the role and we do have user stories that the teams have been working from.
My argument is that the PO should be able to answer the ad-hoc questions that come out of the day-to-day workings of the team. One of our stakeholders said that the teams should know the requirements inside out.
Admittedly the user stories are not as refined as they should be perhaps.

I think the question that I am asking is..... Should the user stories contain enough information for the teams to understand the requirements?

Thanks
Tony


07:53 pm October 13, 2016

> Should the user stories contain enough information for
> the teams to understand the requirements?

They should contain enough information for the team to estimate them, and to know when they have been satisfied. Apart from that, user stories are just placeholders for conversations about the requirements, and which allow understanding to emerge.

If your stakeholder is right, and the team can reasonably understand the scope up-front, then where is the need for dialog, debate, and emergence which an agile way of working provides? What sort of "agile transformation" is that stakeholder expecting and hoping to sponsor?


05:49 am October 18, 2016

The question is how concrete are the requirements? If there is a substantial document in existence, chances are that these are pretty much worked out already. You mention that there is a Transformation going on which for SCRUM usually is an alarm bell. With the requirements doc and other PM artifacts already in place, my 'fear' is that the decision to go Agile is more or less a political one and be wary of negative influence that try to make a case against Agile. It's like they are building in 'safety nets' by doing these requirements upfront.

You could split the Doc in chunks (Epics) and sub-chunk them further into User-Stories. But to then discuss the user stories again with the business seem to be re-doing the requirements gathering and the business wouldn't like it. Maybe that's why you get people saying that the developers should know the requirements.

The question in this case is why go Agile for this project and not just do the Waterfall. If you can deliver workable software in sprint releases (parts of the project that can go LIVE) then yes Agile. If you only deliver the project LIVE when everything is developed then just go Waterfall.

It's either SCRUM from the start, or no SCRUM... in my humble opinion.




06:20 am October 18, 2016

And what I've experienced so far in organizations that are in a Transition Phase:

it's like having a soccer team like Real Madrid play on a cricket field, following hockey rules, with an ex-rugby player as a PO and an audience that expects Ronaldo to do at least 15 Slam-Dunks....

:)


02:47 am November 2, 2016

The requirements document is a good legacy to use/reference by PO. And you're right: if the team goes Scrum - PO is the one who should chunk, prioritize, explain and elaborate. Potentially shippable increments is a huge benefit s/he will get out from that.


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.