Requirements Documents

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

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

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

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

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.

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

:)

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.