Please enable JavaScript.
Coggle requires JavaScript to display documents.
Requirements and Data Gathering (ITIN) - Coggle Diagram
Requirements and Data Gathering (ITIN)
Requirements
User Story
if vendor involved: ADO is still managed by BAs, to ensure completeness of requirements/description. validating with BUs
BRD is usually attached to the ADO work item as a supplementary documentation. basic document where requirements are described (e.g., set-up criteria, dropdown options, etc.)
broken down into tasks, to include evidences/results
prone to scope creep. especially for complex/big project (e.g., change 1 has dependencies with other module/change; during UAT, other changes are noticed/required before team can release). no approval to release to production if additional requirements are met
presentation of requirements
early product inspection
initial demo
for some teams, no mid-sprint inspection. additional requirements are found during UAT
reviewing just to comply, versus reviewing prototype with quality
sprint review / demo
only used when straight-forward/non-complex enhancements;
otherwise, UAT is performed
Prototype
traceability matrix
for BAU, sometimes no traceability matrix
differences in requirements / processes / formats per department or business, causes issues in integration and coordination
People
Product Owners
learning curve for submitting ACR/tickets. sometimes, because of this, BAs step in and create the ticket on behalf of PO
BAs introduce Agile and other processes to them (including submitting ACRs)
need to influence to review/inspect early, instead of discovering issues only during UAT
difficulty in introducing new processes to POs
open to re-negoiation of ranked work items
sometimes, new PO/resource comes in the middle of the sprint, team needs to onboard them again, and sometimes new PO will introduce new requirement
challenges with schedule of UAT/testers
missing chief PO (ITD BA needs to step-in/decide on behalf of business)
Product Manager
your Product Team
QAs
Developers
other Product Teams (dependencies)
ITID Infrastructure
ITD Communications
Application Change Management (ACM)
e-Learning team
IT Training team
CPD Helpdesk
L1 (AskIT)
L2 (TCS QAs)
Vendors
CSU (consumption)
other BAs
sometimes, MSP will create SNow ticket or ADO work item. ITD BAs will review and prioritize after.
Trainings
team KTs / brownbag sessions
none for most teams
brownbag session about CBAP sessions
onboarding
for some teams, there are onboarding program / tool kits / checklists
templates shared to new BAs
prod support / sit-in
self-learning
Via QRGs / manuals
Via e-learning videos
Via Document of Understanding (for TCS)
Tools and Templates
ADO Work Item templates
Feature
Use Story
Poker Planning
acceptance criteria, definition of done included in ADO
EPIC (Approved ACR)
once ACR is submitted, BU has no access to edit
SDLC documents
High Level Solution Design (HLSD)
Requirements Definition Document (RDD)
no standard template used
Solution Design Document (SDD)
Peer Review
no standard repository for documentation (e.g., Confluence/WIKI)
for other teams/projects, documentation is stored in Project SharePoint. related/linked to ADO work items
old docs: MD50, etc (for waterfall projects)
other templates
unit testing results added to ADO (tasks)
test execution results are documented in ADO (tasks)
Process and Technique
Elicitation and Collaboration
ACR request and approval
ideal: reviewed and endorsed by BU
sometimes: BUs are hesitant in submitting ARC, so submitting comes after as a formality
if vendor involved: background discussion and MSP costing, before ACR submission (BUs are involved for completeness of details, and determine the order)
no defined roadmap, but release planning happens periodically
no definition of story points
meet and prioritize with product owners
for some teams, for standard changes (pre-approved by CAB) > no ACRs. normal changes > with ACRs
yearly discussion of list of Epics (excel file) for the whole year. once agreed, users submit ACRs. sometimes, temporary Epics are manually created
gather change details: who requested, details from ACR
before ACR submission, BU schedules a meeting to understand feasibility of ACR
before endorsed by NS, ACR details are complete; if not, requests for the template or emails the BU for compelete requirements doc
get any available documentation; or if lacking doc > interview the business (involved in the process) or conduct a FGD, or observe the process
workshop to gather requirements (project)
Analysis
updates to the backlog
additional requirements, BAs update in ADO
roadmap set for the year, some are spillovers from previous year, some are entirely new; early assessment of feasibility of enhancements
as a <role>, i want to <action> so that <value>
1 report = 1 user story
prioritization
based on BU prioritization/discussion
if new epics are added within the year, reprioritization/discussion with business is conducted
based on urgency
based on BU prioritization/ranking, with help from the product team's assessment/capacity/other commitments
sizing
no definition of story points for some teams
other teams, points are used for estimated number of hours
fibonacci is used (based on complexity and hours required)
Design
UI/UX
Mock-ups / Prototypying
powerpoint
paint
word doc
balsamiq
plain HTML coding
excel (for data/reports-related)
appsdiagram.net (web-based free access, for non-sensitive info)
mirro/whiteboard
developers interview users directly how they like the UI to look
SnagIt TechSmith
figma
Abacus (business process modeling)
ADO Feature / User Story
release > epic > user story
release > epic > feature > user story
release > user story (for small changes)
Review and Approval
Via ITD email review/endorsement chain
Via ITD presentation/meeting to BU
Follow ups via email / MS Teams chat / meetings
waiting time: depending on BU's availability (1-5 days)
for some teams, BU has access to ADO, others: none
internal discussion between PO and dev team, turnaround time is quick
if additional changes are required: triaged if critical/priority. if non-critical, goes back to the backlog as a separate ADO workitem (user story or Epic)
sometimes additional requirements come up in the middle of the sprint: a) straightforward changes, team accepts, b) for complex ones, we ask BUs to submit new ACRs
development cannot start due to back and forth discussion (due to generic requirements included in ACR)
difficulty in reviewing prototype so review had to be put on hold (non-critical feature)