What is an appropriate quality standard for requirements specifications?

Question

In my role as a Business Analyst working for a offshore company (7 developers, 4 QA, 1 PM, 1 Architect) but being onsite, I go through the Business Requirement Document's, Epics and Stories briefed by Product Owners (PO) and write a more detailed specification for an offshore team. Its a 2 week sprint, and the stories, designs often come not more than 2-3 days before the sprint planning day. Not to mention about that the designs are handled by a separate team in itself, and sometimes there is a disconnect between PO and Design as well. Furthermore there are clients who have their own Product Owners and Designers doing last minute requests, changes, priorities to customize or white-label it for them.

To add more complexity, I am NOT involved in the PO-Design or PO-Client discussions. With this stated I try best to read the documents on wiki, see whatever designs that are available currently, while Design is trying to polish and fine tune them (these are mostly outdated initial bare minimum designs), read Business Requirement Documents-BRD (which are often at a high-level and mostly not updated as what is on the Design currently)

So with these limitations, I take up the stories (about 8-10) that are slated for the offshore team specifically

1. Review stories that they are work ready (documented responsibility said by Client - seems pretty broad and covers most of the work below),
2. Define edge cases
3. Provide more detailed information on every line of Acceptance Criteria (AC)
4. Add necessary resources to the story/feature description (any content like XML that needs to be used, any Wiki that needs to be pointed for more information or Design assets that are missing)
5. Co-ordinate with Design, PO, PM, Scrum Master to get everything seamless
6. Facilitate conference calls to run through all the stories (Story Time) every Sprint Thursday explain them as much as possible
7. Answer their queries/ clarifications that come in everyday (these are sometimes too obvious and unclear questions - takes my whole day often)
8. Demo for stories completed by Offshore team (preparing the Wiki page, information, test data)
9. Do Acceptance Tests for offshore teams stories, prepare a document and pass it over to the actual POs
10. Daily review of Rally discussion board and answering them, reaching out to the necessary Tech leads and developers onsite to get information on this
11. Review test cases and sign-off

With all these things done, when any small issue creeps in stopping the story completion per the definition of done. The offshore team completely point fingers at me.

What is an appropriate quality standard for a requirements specification? How can we design a process to more flexibly adapt to changes in requirements?

Answer 1

This is still a very complex question, and I think it is possible that an answer will nail a part of it and miss the whole. I'm still thinking about the problem, but in the interim, I found the following quote today

The design specification must be governed differently than the requirements. If the requirements were appropriately governed, and if the requirements predominantly begin with the term “The system shall..,” then our design leads and developers need to take new factors into consideration when governing the design phase. Since the design is the translation of the business and technical requirements into a specification that can be developed, at this point in the project we must consider the following

What follows is some criteria for translating requirements into a design spec.

I believe you have a quality assurance problem, and the resolution is to look at the process of transforming inchoate stories into produceable designs. Nominally there are three stages that could fail.

1. The underlying data you get could be flawed. Looks like you get LOTS of data, and I have to wonder if some of the sources are more reliable than others. If prioritizing those sources that result in improved requirements and design specs wouldn't make the process better.
2. You. You may lack the Knowledge, Skills, Abilities etc. needed to work the process. If so, then your manager needs to arrange for training to improve your skill. I don't say this to insult you, but to be comprehensive.
3. Output - perhaps the requirements are good, but the translation to design specs is inadequate. Perhaps the interface between you and the design team has some noise in it. (Some of the material that I edited out of your question and recommended you take to Workplace SE may support this thesis, but I would seek objective confirmation).

If I were in your shoes, I would be looking for a couple of things.

• Some kind of agreed upon quality metric - some objective, agreed upon standard that we could use to manage improvement. Number of requirements that are implemented without change. Number of meetings required to produce a successful requirement. But it has to be a metric that is accepted by you, your management, and your downstream customers (those who are complaining). Find out what the quality is today, and commit to improve it by N% by X date. (Even if the best you can do is "25% of requirements are successful, but by June 30 30% of requirements will be successful", or "17% of requirements need 3 or more meetings to clarify; by 1 July, that number will be 10% of requirements need 3 or more meetings..."
• Root cause analysis of every failed requirement. Why was this requirement unsatisfactory? What needed to be changed, and at what point in the process should the error have been detected? Did you not have the right data? Is the design team using a different definition of common terms?
• Management support. I infer from your question that you've got some dysfunctional and out of control processes, and that these are generating friction within the company. All the involved parties (you, design team, PO, corporate management, the bottom line, the customer) will benefit from reducing that friction and improving the process. But changing processes without the active support of both parties managers is ... risky.

You're working in some kind of scrum variant, and I'm not initiated into the Gospel of Scrum; I'd love to hear the commentary of some of our Deacons of Scrum on the problem. Based on my limited understanding of scrum, I think you have a major problem. My impression is that scrum is supposed to facilitate more effective communication, and it doesn't seem to be doing this in your case.