business analysis case study: adding business value using agile

Download Business Analysis Case Study: Adding Business Value using Agile

Post on 10-Feb-2017

218 views

Category:

Documents

1 download

Embed Size (px)

TRANSCRIPT

Business Analysis Case Study: Adding Business Value using Agile within Waterfall

16th March - IIBA Event - BaselBusiness Analysis Case Study: Adding Business Value using Agile within Waterfall

2IntroductionAbout meBrian Hill - CBAP

Freelance contracting in projects (IT and Process) for 10+ years

Committed to professional development

Strong sense of ownership

Focused on delivering value to the business and meeting stakeholder expectations

2

3IntroductionObjectivesTo demonstrate the value a Business Analyst can bring to Project delivery and to the Business, focusing on a case Study incorporating Agile within WaterfallExpected outcomeIncreased understanding of the Business Analyst role

Demonstrated application of the BABOK framework

Demonstrated Agile thinking and practices - even within a Waterfall project

Clarity on how a Business Analyst can add Business Value

3

4Initial assessment on joining the projectBusiness NeedTo provide a major update to an in-house, User Service Self Service portalOrganisational Process Assets

Enterprise Architecture

Expert JudgementProject Management to align with Internal company specific project methodology (~ PMBOK)

Mandated use of Requirement Management (RMS) and Document Management systems (DMS)

Two development teams and two systems, geographically dispersed, mix of CSV/ Agile

First release with a Business Analyst (BA) - therefore a challenge to demonstrate BA value

Fixed project duration and go-live date, fixed budget scope fluid at start of projectThe challengeAs a business analyst, determining:Is my role to simply document requirements OR is my role TO be a leader and deliver real business valueAs a projectAvoid conflict and simply overpromise and under-deliver ORPractice Agility to deliver optimal value within complex set of constraints

4

5Checkpoint SynopsisInternal PM methodology mandates waterfall approach

Waterfall approach requires scope/ time/ budget fixed

CSV mandates fixed scope & baselined documentation,

Agile methods are light on documentation, requirements change, scope variable

Pure Agile would spectacularly fail CSV and internal PM methodology complianceKey FindingsFull Development and Test Team Resources active for duration of the Project

Business Value related to maximising value from these teams

Business Stakeholders present an initial set of requirements which constitute scope

Requirements incomplete, associated effort and prioritisation unknown

Ability to meet stakeholder needs uncertain

Project Plan including Phase duration not yet defined

5

Business Analysis Planning and Monitoring (BAPM) - BABOK v26

Plan Business Analysis ApproachRapidly perform iterative analysis of the requirements and group by moduleEstablish priority and associated project resource effortsCompare to project resource capacity enabling scope settingStakeholder Analysis

Plan BA Activities

Plan BA Communications

Plan Requirements Management Process

Manage BA PerformanceAs a first step, identify stakeholders and start to determine all constraints (location/hours)

Schedule daily workshops with the SME and Development Team Resources, Plan mandatory trainings (internal compliance for BA), gain system access and authorisation rights

Schedule daily Stand-Up meetings, schedule weekly team meetings

Use of RMS and DMS mandated for baseline/ signed off documents. Use of collaborative tools such as Google Docs, Google Sheets for the elicitation aspect of requirement definition. Common set of criteria agreed to assess, categorise and group the requirements

Creation of a tracking sheet that measures the planned activity for BA (and others) on requirements assessment - this also enabled ability to track original requirements plus uncontrolled scope creep

7Business Analysis Planning and Monitoring (BAPM) tasks

7

8Checkpoint SynopsisScope creep from day 1:

Need to educate stakeholders and manage expectations

Conflicts between stakeholders and availability issues

Caution/ inexperience toward BA role

SME in Americas time-zone, one development team in Poland billing from day 1 on fixed budget with no work to execute, scope not set

Immediate PrioritiesWork with PM to start planning achievable scope and associated effort not yet known, but capacity and phases within waterfall mandated methodology will shape our approach

Keep track on original requirements, and those that are snuck in

Review ALL requirements, start prioritising and getting assessments from SME, dev team 1, dev team 2, testers: assessing effort and system interdependencies requiring change

Developing my own system context and expertise while demonstrating the role, and value of the BA role, to the project stakeholders

8

9Elicitation

9

10ElicitationMore than just documenting requirementsA popular misconception is that Business Analysts simply document requirements.

This section from BABOK clearly differentiates how documenting (requirementelicitation results is just one part of the Elicitation process, which is part of the larger Business AnalysisPrepare for Elicitation

Conduct Elicitation Activity

Document Elicitation Results

Confirm Elicitation ResultsUsing stakeholder analysis, Organisational Process Assets (tools for virtual meetings, online document collaboration tools), I set up intensive schedule of requirement elicitation sessions - a mix of document analysis, interviews, daily workshops with SME/ Usability Expert and other key stakeholders - with a set agenda for each session planned and circulated in advance

Each session handled differently, but working under time pressures the decision to use collaboration tools proved valuable, as updates were flowing in real time and overnight between sessions (especially usability expert developing mockups and inserting to elicitation documents)

Online collaboration tools were used to document the elicitation results, including targeted feedback and clarification in addition to a standalone open actions google sheet. This mitigated the risk of the Business Analyst and SME availability (timezones) hindering progress - and allowed for rapid iterations to finalise individual requirement definitions

Due to the documentation technique and daily stand-ups, requirement elicitation could be rapidly confirmed, communicated to all stakeholders, and the baselined requirement stored in the RMS as record of truth, triggering individual requirement Design pre-work in parallel to the ongoing elicitation of other requirements

10

11Checkpoint SynopsisBAPM highlights that scope needs to be set asap

ALL requirements need to be estimated and prioritised

Defining in Waterfall approach will erode Business Value

SolutionImplement daily calls and workshops with key stakeholders via hangouts

Morning Stand-Up: 15 minutes focusing on key actions, blockers, and to build team identity.

Utilise google documents to collaborate during definition

During the workshop, requirements are reviewed for completeness and actions to be assessable

Requirement prioritised (1-10 not high/ medium/low)

First estimates from devs/ test of effort for design/ build phase provided

Interdependencies identified

11

12Requirements Management and Communication

12

13Requirements Management and CommunicationThe Waterfall v Agile DilemmaIn Waterfall, Scope and Requirements must be Baselined by end of Definition.In Agile, fixing scope and requirements is not very agile.In Validated environments, requirements live forever, projects do not.Manage Soln ScopeAnd Requirements Manage Requirements Traceability

Maintain Requirements for re-use

Prepare Requirements Package

Communicate RequirementsReview/ estimate/ prioritise used to help business make a scope setting decisionRequirements being elicited, validated and verified prior to baselining in RMS

Within RMS, requirements will be traced to other (dependencies), User Requirements, Design Specifications and Test Cases

Requirements live forever, therefore essential to manage traceability and link to change requests and previous versions of the requirements. Defects or enhancements decision can be made by referring to the overall baselined requirements (operational, not just release)

Determine the best way to communicate a set of baselined requirements.Internal Project Methodology mandates published extract of the release plus new overall requirement baseline to exit Define Phase

More formal for Sponsors, PM - SME, Dev, Test all actively engaged in elicitation/ validation/ verification process

13

14Checkpoint SynopsisTools working well and all teams engaged and aligned

SMEs integrated and active

PM working on PMM deliverables and aligned with BA approach

Daily Stand-Ups working well robust dialogue, everyone aware of priorities

Prioritisation and estimation taking place plus scope creep addressed

Critical requirements verified and Design effort for these being reduced by development teams

Immediate PrioritiesManage scope by performing capacity based planning

Make any excess demand over budgeted capacity a business problem they choose the scope we can accept

High level estimates and prioritisation of requirements after first iteration of reviews provides assessment that demand exceeds capacity substantially