Business analysts are often responsible for identifying the features and functionalities included in the scope of work for software development, sprints, phases, milestones, etc.
A common trend is that we tend to document and analyze what is included, presenting this to our stakeholders for review, confirmation, and approval, depending on the company's established processes.
However, we rarely document and state what is OUT of scope and present this information as equally important as what is IN scope.
For example, the scope of work might include "login functionalities" in the software development process. The assumptions behind this can differ significantly: for business executives and stakeholders, "login functionality" might mean:
Logging in via email
Logging in via Google Account
Logging in via Facebook
Ability to restore passwords
CAPTCHA on the login screen
However, for the development team focused on delivering small increments of value, the first deliverable might only include logging in via email, excluding items 2-5.
This discrepancy leads to what I call an “assumptions gap.” The development team believes they have successfully delivered what was promised, but when they showcase the deliverables to business executives, they are questioned about why items 2-5 are not ready yet.
To avoid this, make sure you clearly describe what IS in scope and what is OUT of scope. Clarity and transparency result in long-lasting working relationships.
#BusinessAnalysis #ProjectManagement #ScopeManagement #SoftwareDevelopment #TeamCommunication #StakeholderEngagement #ClearCommunication #ProjectSuccess #Agile #Transparency
Kommentare