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?

  • 4
    Hi Oneworld, there are lots of questions here, which makes it hard for users to vote on the best answers, as some will only choose to answer certain questions. I suggest you edit this down to focus on a specific question and then flag it and we can look at reopening it. It's also possible that you have more than one question you can post separately, as long as the questions are focused. Good luck! :)
    – jmort253
    Apr 28, 2013 at 18:00
  • I have now made it more centered around requirements, hope this would help to open up this question.
    – oneworld
    Apr 30, 2013 at 19:31
  • 2
    I've done a quick edit - some of the material I've removed is a candidate for workplace.stackexchange.com. I've tried to focus the question on the issue which is most relevant to PM - your requirements spec is being held to an unreasonable standard of quality (100% error free). That might be a goal, but I think they have to give you a path to get to that goal, and I suspect you're not the only actor in the process, and a 100% goal will require heroic effort by all actors in the process.
    – MCW
    May 1, 2013 at 10:55
  • +1 Thank you so much for editing. Your answer is also great, and I hope I can convey this way to my upper management and my teammates. Appreciate it! Hope the question gets reopened and suggestions flow in!
    – oneworld
    May 1, 2013 at 15:08
  • 1
    Nice editing work @MarkC.Wallace and oneworld! I'll go ahead and reopen. Because this is a subjective question, answers should ideally be thorough. Please leave clarifying comments to help others provide good, complete answers. Good luck! :)
    – jmort253
    May 2, 2013 at 1:53

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

  • +1 for two things: mentioning root-cause analysis for failed requirements, and metrics to improve. I wonder if these can be practically applied at a workplace without causing even more friction though: there are finger pointing folks, and it could take some travels-face to face team building efforts to merge the perspectives. Sep 29, 2015 at 19:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.