Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements and Data Gathering batch 4 - Coggle Diagram
Requirements and Data Gathering
batch 4
Requirements
Traceability Matrix
no traceability since team has roadmaps being followed
new enhancements are logged as separate ADO work item
User Story
if there are dependencies (e.g., other applications or projects impacted), issues will only be identified during implementations.
sometime criteria is not clear, or POs do not know which option they like
Presentation of Requirements
feature roadmap / release planning
People
Product Owners
POs/BUs are visual and will react only during UAT when they get to absorb or get to play with the system
dependent on the product team for the options
misaligned understanding between PO and product team on what is being developed
additional UAT participants, not part of the initial mockup approval, leading to additional requirements/delays due to revisions
product team has regular cadence with POs to clarity of the requirements, and identify US included in releases
Product Manager
Your Product Team
devs
QAs
will prepare for the UAT (including who are the participants)
test case creation
BA
provide business value during refinement
acts as internal POs
use ppt or excel as interim backlog, will put in ADO once finalized
taking a lot of roles due to constraints on resources (role confusion/blurring), or due to confidentiality
semi-scrum master
lack of technical resource (e.g., seek technical direction or when team needed to integrate, etc.)
Other Product Teams (dependencies)
dependencies will cause noise/reaction from other impacted product teams
Vendors
BAs are "blind" or not involved in the overall requirements discussion
Tools and Templates
ADO Work Item Templates
details such as acceptance criteria is documented in ADO
SDLC Documents
documentation
some requirements are uploaded in ADO
other documents are stored in separate SharePoints sites
not all are familiar with functionalities in ADO what teams/projects can be maximize
Process and Technique
Elicitation and Collaboration
ACR request and approval
conduct stakeholder meetings to gather information about the enhancements
recurring
BA gathers info and discuss with the team, will be sent to the BUs for their initial approval
issue reported to the team, and team will identify with the stakeholders if change requests are required
discovery sessions
stakeholders will present/walk through the processes, and what the team will be building
Analysis
updates to the backlog
once approved by BUs, will be included in backlog refinement with the team
every release has 2 sprints
if UAT feedback can be accommodated within the same ACR, team will review and confirm first
prioritization
initial ranking is provided by the team. then BUs will review and provide their prioritization, and will reprioritized if necessary
BA make sure to align with stakeholders for the Roadmap (agreed and approved features)
sizing
point system
pre-defined factors for a certain size/point (e.g., dependencies, risks, etc.)
devs and QAs will agree on size of US
Design
UI/UX
Mock-ups / Prototypying
PPT
Figma
Excel
Review and Approval
Review and Approval
demo by product team
hands-on by BU
BUs will need to see the developed system before they can review and approve. most of the time they will still make changes even mock-ups have been provided. product teams will need UAT to get the feedback from BUs
scope creep is prominent during UAT period esp. due to additional stakeholders/testers not part of the initial mock up approval
Trainings
onboarding
no training/onboarding
team KTs / brownbag sessions
no KTs / transition plans
reliant on mentors / current or senior BAs to share documentations / learnings
self-learning
BAs use documents, and rely on previous experiences as BAs
links
a lot of BA development trainings are only exclusive to ADB staff, and not accessible to contractors
over-all BA training
e.g. writing user stories (test-driven development standards) or ACRs