role business analysts scrum
Listen Sie alle Betriebssysteme auf, mit denen Sie vertraut sind
Prominente Rolle von Business Analysten in SCRUM:
Ein Business Analyst, der kurz als BA bezeichnet wird, spielt eine sehr drastische und wichtige Rolle in GEDRÄNGE .
Diese Person ist die Verbindung zwischen dem Product Owner / Kunden und dem technischen IT-Team. Obwohl wir auf unserer Website zu BA auf mehrere Tutorials gestoßen sind, wird dieses Tutorial irgendwie einzigartig sein und Ihnen die Bedeutung von BA in SCRUM erklären.
Lass uns erforschen!!
=> Überprüfen Sie ALLE Business Analyst-Tutorials hier.
Was du lernen wirst:
- Verantwortlichkeiten eines BA
- Business Analyst als Product Owner
- Business Analyst als Teammitglied
- Bedeutung und Rolle von Business Analysten im SCRUM-Team
- Warum passt eine Qualitätssicherung am besten zu diesem Job?
- Literatur-Empfehlungen
Verantwortlichkeiten eines BA
Es gibt mehrere Rollen von Business Analysten in Scrum und es gibt bestimmte Verantwortlichkeiten, an die sich ein BA halten sollte.
Einige selektive unter ihnen sind unten aufgeführt.
- Pflege des Product Backlogs basierend auf der vom Product Owner bereitgestellten Priorisierung.
- Analyse der Kundenbedürfnisse und Suche nach Lösungen, um diese zu adressieren.
- Erstellen der Anforderungen in Form von User Stories mit entsprechenden Akzeptanzkriterien.
- Wenn die User Stories bereits vom Product Owner erstellt wurden (mit Akzeptanzkriterien), überprüfen Sie sie, um sicherzustellen, dass alle Geschäftsregeln abgedeckt sind und die Akzeptanzkriterien die User Story-Funktionalität erfüllen.
- Arbeiten Sie mit dem Product Owner und den Stakeholdern zusammen, um den Umfang zu verstehen, Verbesserungen der Anforderungen vorzuschlagen usw.
- Vorbereiten von Dokumenten wie Drahtgittern, Entwurfsablauf, Benutzeroberfläche usw. nach Bedarf.
Abgesehen davon a Business Analyst ist ein wichtiger Teilnehmer an den Brainstorming-Sitzungen, wenn sich das Team trifft, um den Rückstand des bevorstehenden Sprints zu besprechen. Die BA leitet das Team, hilft ihnen, die Anforderungen zu verstehen, und muss manchmal sogar die Implementierung genehmigen.
Er arbeitet auch eng mit den Qualitätssicherungsorganisationen zusammen, z. B. analysiert er die Testabdeckung, wandelt reale Anwendungsfälle in Testfälle um, bietet Einblicke in das Testen komplexer Funktionen usw. Die BA nimmt auch an der Planungsbesprechung teil, um das Team bei Schätzungen zu unterstützen, indem sie ihnen hilft Verstehen Sie den Fluss, die Komplexität und die Abhängigkeit.
BA muss immer über den neuen Trend auf dem Markt informiert sein, weiter innovativ sein und über den Geschäftsbereich, für den das Produkt hergestellt wurde, auf dem Laufenden bleiben.
Business Analyst als Product Owner
Abhängig vom Kunden und dem Unternehmen kommt es vor, dass einige Unternehmen den Business Analyst als Product Owner haben. In diesen Fällen ist der BA die Kontaktstelle für alle Abfragen. Der BA wird dann zum Vermittler zwischen dem Team und den Stakeholdern.
Die BA muss die Anforderungen der Stakeholder verstehen, ihre Überlegungen, das Geschäft voranzutreiben, und was (und wie) das Geschäft wachsen soll. Auf der Grundlage der Anforderungen der Stakeholder muss die BA dann die Dokumente, User Stories erstellen, die Storys priorisieren, dem Team helfen, sie zu verstehen, ihre Fragen dazu zu beantworten usw.
Das Wichtigste dabei ist, dass dies ratsam ist, wenn der BA physisch verfügbar ist und nicht in einer anderen Zeitzone geolokalisiert ist, um die „Kommunikationslücke“ zu vermeiden.
Wenn der BA wie beim Product Owner in einer anderen Zeitzone geolokalisiert ist, kann er nicht jedes Mal angesprochen werden. Die einzige Möglichkeit zur Kommunikation besteht in E-Mails, Chats oder Anrufen. Dies kann zu einem Mangel, einer Lücke und sogar dazu führen Missverständnisse manchmal.
Nach meiner Erfahrung sollte dies befolgt werden, wenn der BA in Ihrem Büro neben Ihrem Team sitzt, damit Ihre Arbeit nicht behindert wird und er leicht erreichbar ist. Aus Sicht eines BA besitzen sie das Produkt im Namen der Stakeholder / Kunden, treffen geeignete Entscheidungen und müssen sogar neue Fähigkeiten erlernen, einschließlich des Lernens einiger technischer Aspekte der Entwicklung.
Ein Business Analyst als Product Owner ist ein zusätzlicher Vorteil, da der Business Analyst das Produkt sehr gut versteht und auch Prioritäten und Aufgabenbereiche ausgehandelt werden können.
Business Analyst als Teammitglied
Die andere Option besteht darin, den Business Analyst als Teammitglied zu haben, da der Product Owner nicht jedes Mal verfügbar ist. Wenn der Business Analyst ein Teammitglied ist, helfen sie den Kollegen bei der Rückstandsbereinigung.
Ein Business Analyst als Teammitglied ist vorteilhafter, da das technische Team es einfach und bequem findet, mit dem BA zu kommunizieren, um Klarstellungen oder Diskussionen zu erhalten. Die BA arbeitet auch eng mit dem QS-Team zusammen, um Tests durchzuführen, d. H. Die Abdeckung, die abgedeckten Anwendungsfälle, versteckte Anforderungen oder Zuverlässigkeit oder Auswirkungen zu analysieren.
Manchmal sind die vom Product Owner geschriebenen Akzeptanzkriterien vage und nicht klar. Als Teammitglied liegt es in der Verantwortung der BA, ausführliche und gut erläuterte Akzeptanzkriterien zu schreiben. Wenn das Team weitere Informationen benötigt, erstellt der BA auch Drahtgitterdokumente, Flussdokumente usw., um dem Team das Verständnis der Anforderungen zu erleichtern.
Bei Großprojekten, bei denen die Module auf Teams verteilt sind, ist ein BA für mehr als ein Team ebenfalls ein zusätzlicher Vorteil. Da der BA in allen Teams gleich ist, kann er über die Interoperabilität der Module nachdenken, wie sich neue Funktionen oder Updates auf die anderen Module auswirken usw.
Dies würde den technischen Teams sehr helfen, solche Aspekte zu berücksichtigen, die in den User Stories oder Akzeptanzkriterien nicht immer erwähnt werden.
Bedeutung und Rolle von Business Analysten im SCRUM-Team
Die Rolle von Business Analysts in SCRUM ist sehr wichtig für den Erfolg eines Projekts. Ihre Beteiligung beginnt direkt mit dem Verständnis der Kundenbedürfnisse für die Sprint-Demo. Sie sind die erste Anlaufstelle für das technische Team zur Klärung. Sie sind in den Anfangsphasen eines neuen Projekts und in großen Projekten noch wichtiger.
Der Product Owner ist nicht immer ein guter Autor, manchmal hat er einen technischen Hintergrund und daher liegt es in der Verantwortung des Business Analyst, die Geschichten, die Akzeptanz, die Drahtmodelle usw. zu schreiben.
In meinem Projekt war unsere Bestellung nicht so gut mit Dokumentation und selbst die geschriebenen User Stories waren nie mehr als 2-3 Liner, während die Akzeptanzkriterien nur ein Liner waren. Es war der Business Analyst, der sie modifizierte, erklärender und ausführlicher machte.
Sogar manchmal schrieb unsere Bestellung User Stories mit 21 oder mehr Story Points, und daher musste der Business Analyst zusätzliche Zeit und Mühe aufwenden, um sie aufzuschlüsseln und mit dem Product Owner zu priorisieren.
Sie können sich vorstellen, was passieren würde, wenn es keinen Business Analyst gibt und Ihr Product Owner eine User Story wie 'Als Kunde möchte ich alle Bankgeschäfte für mein Konto ausführen' mit Akzeptanzkriterien wie '
- Der Kunde sollte sich anmelden können.
- Der Kunde sollte in der Lage sein, Transaktionen auf meinem Konto durchzuführen.
- Der Kunde sollte in der Lage sein, meine historischen Aussagen usw. herunterzuladen.
Meiner Meinung nach würde diese User Story sogar mehr als 34 Story Points enthalten, daher muss sie weiter aufgeschlüsselt werden. Für das technische Team würde sich die Situation verschlechtern, wenn nicht die richtigen Flussdiagramme und UI-Bildschirme (die erstellt werden müssen) bereitgestellt werden.
Dies würde zu einem fehlgeschlagenen Sprint und damit zu einem fehlgeschlagenen Projekt führen. Sofern der Product Owner kein ausgebildeter / geübter Business Analyst ist, muss einer im Team sein.
Warum passt eine Qualitätssicherung am besten zu diesem Job?
QA ist eine Person, die die vorgeschlagene Lösung für ein Problem / eine Anforderung durch Testen überprüft. Daher sind die Business Analysten / Stakeholder / Product Owners sehr gespannt auf das Feedback einer Qualitätssicherung. Die Beteiligung eines BA am Testen ist kaum mehr als das, was es in der Entwicklung ist.
Ein Business Analyst arbeitet bei der Überprüfung der Testfallabdeckung eng mit einer Qualitätssicherung zusammen, um einen Einblick in verborgene Abläufe oder Anforderungen / Auswirkungen zu erhalten. Durch diese Art des Wissensaustauschs (von der BA) verstehen sie die Produktfunktionalität, die Geschäftsregeln, die Kundenerwartungen, die Abläufe, Abhängigkeiten und alles vollständig.
Die Qualitätssicherung testet immer aus der Sicht des Endkunden, der das Produkt verwenden würde. Daher sind die Chancen, dem Kunden bei Verbesserungen und Verbesserungen des Produkts zu helfen, größer (im Vergleich zu einem Entwickler). Entwickler entwickeln das Produkt für die angegebene User Story und die festgelegten Akzeptanzkriterien, denken jedoch nicht immer darüber nach, wie ein Kunde das Produkt verwenden würde .
In der Entwicklung sind die Implementierung eines Produkts, der Ablauf und die Regeln genau definiert, aber das Testen basiert vollständig auf logischem Denken und der Fähigkeit, aus der Sicht der Endbenutzer zu denken.
Die Qualitätssicherung kann aufgrund der zahlreichen Möglichkeiten, die sich in der täglichen Arbeit bieten, in die Rolle des Business Analysts bei SCRUM aufgenommen werden.
Empfohlenes Lesen => Karriereschicht von einem Tester zu BA
Für eine Qualitätssicherung ist es sehr einfach, in folgende Rollen zu gelangen:
- Studieren Sie die Anforderungen sehr gründlich und weisen Sie auf die Lücken in Überprüfungsbesprechungen / Brainstorming-Sitzungen usw. hin. Versuchen Sie, über bessere Lösungen nachzudenken und diese mit dem Team und dem BA zu besprechen.
- Seien Sie aufmerksam bei Anrufen mit dem Product Owner, stellen Sie Fragen und teilen Sie Ihre Ergebnisse. Dies erhöht das Vertrauen des Product Owner, der Ihr Interesse an dem Produkt zeigt.
- Passen Sie sich zwischen BA und Entwicklungsteam an, bei Klärungen oder Zweifeln sollten Sie Ansprechpartner für die Entwickler sein.
- Richten Sie den Testprozess ein und entwickeln Sie ihn weiter. Ändern Sie ihn, um erfolgreiche Sprints zu erzielen.
- Achten Sie bei Produkten mit ausgefallenen Benutzeroberflächen auf neue Trends und schlagen Sie solche Verbesserungen vor.
- Verstehen Sie das Produkt vollständig rein und raus.
- Bauen Sie ein starkes Wissen über Ihre Stakeholder und deren Erwartungen auf und teilen Sie Ihre Erfahrungen mit ihnen.
Dies bedeutet auch, dass Sie Ihre Fähigkeiten verbessern müssen, um in die BA-Rolle zu gelangen. Auf dem Markt gibt es mehrere Kurse, die sowohl die Grundstufe als auch die Fortgeschrittenenstufe umfassen.
Sind Sie ein BA / QA? Haben wir zu Recht auf Ihre Rolle hingewiesen? Oder glaubst du, wir haben es verpasst? etwas, das Sie einzigartig durchführen? Wir würden uns freuen, von Ihnen zu hören. Fühlen Sie sich frei, sie mit uns in den Kommentaren unten zu teilen!
=> Besuchen Sie hier, um die Business Analyst-Reihe für alle zu sehen.
Literatur-Empfehlungen
- Scrum-Artefakte: Product Backlog, Sprint Backlog und Product Increments
- Gibt es eine Start- und Stoppgrenze für die Rolle der Qualitätssicherung in Scrum?
- 39 Beste Business-Analyse-Tools für Top-Business-Analysten (Liste von A bis Z)
- Rollen und Verantwortlichkeiten des Scrum-Teams: Scrum-Master und Product Owner
- Karrierewechsel vom Tester zum Business Analyst - Eine Schritt-für-Schritt-Anleitung
- Starten Sie Ihre Karriere als Business Analyst: Eine Karrieremöglichkeit für Sie
- Executive Cum Training Coordinator für IT-Support und Geschäftsentwicklung Pune
- Fehler-Triaging in Scrum: Wie ist es in einem Scrum-Setup organisiert?