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
- Review stories that they are work ready (documented responsibility said by Client - seems pretty broad and covers most of the work below),
- Define edge cases
- Provide more detailed information on every line of Acceptance Criteria (AC)
- 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)
- Co-ordinate with Design, PO, PM, Scrum Master to get everything seamless
- Facilitate conference calls to run through all the stories (Story Time) every Sprint Thursday explain them as much as possible
- Answer their queries/ clarifications that come in everyday (these are sometimes too obvious and unclear questions - takes my whole day often)
- Demo for stories completed by Offshore team (preparing the Wiki page, information, test data)
- Do Acceptance Tests for offshore teams stories, prepare a document and pass it over to the actual POs
- Daily review of Rally discussion board and answering them, reaching out to the necessary Tech leads and developers onsite to get information on this
- 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?