A Good BA ensures all sections of their documents add value. They flush out and define detailed requirements organized and aligned to business goals and scope. A Bad BA fills out a template. They write down disjointed meeting notes from stakeholder interviews and call them requirements.
A Good BA defines accretive requirements. A Bad BA uses words like may, shall, and should. A Good BA includes notes and supporting information in their documents for increased reader understanding. A Bad BA does the bare minimum, forcing conference calls to explain written requirements.
A Good BA is organized and manages open item trackers for their documents. They can accurately communicate work remaining and blockers to closure. They anticipate design challenges and drive clarity through their requirements. A Bad BA lets the tech team do their work for them by flushing detail through tech design questions.
A Good BA partners with the Client to ensure they are prepared for User Acceptance Testing. They ensure the client understands what was documented and categorizes appropriate UAT defects as Change Requests. A Bad BA assumes the client is organized and prepared. They flood the tech team with duplicate, unclear, and as-designed defects
A Good BA is viewed as a critical member of the team’s success. They do their best regardless of whether or not someone is going to read the document. A Bad BA cuts corners and is a replaceable with well-annotated wireframes.
Don't forget to leave your comments below.