Business Analysis Case Study: Adding Business Value using Agile ...

Download Business Analysis Case Study: Adding Business Value using Agile ...

Post on 10-Feb-2017




0 download


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


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


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


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


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


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




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


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


12Requirements Management and Communication


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


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


Delivering Optimal Scope by being Agile within Waterfall15

Optimised Build Phase duration is critical to maximising scope

Define Phase agility reducing design phase duration and increasing build phase - maximising build scope

Manage scope by performing capacity based planning

Business Value from Build Scope maximised by the prioritisation and estimation technique

Operating in pure waterfall would deliver a very small set of scope within time/budget

16Exiting Define Phase Project phases, capacity, in-scope requirements signed off:Final requirements being validated and verified

Design work progressing well on defined requirements - effort to Design reducing

Dev Teams and Test teams demonstrate robust common understanding

Less and less problems to resolve now - we are a well oiled machine

Requirement documentation and traceability become focus

Build sense of team, maintain momentum, and coordinate team efforts for the upcoming transition into Build PhaseSolutionPrepare Requirements Package and formally baseline Requirements

Exit Define phase

Schedule a face to face workshop at end of Design Phase


17Design Phase Face to face workshop: Meet and greet, Design document sign-offs, bombshells and a planning lesson:Conducted 3 day workshop, bringing most key stakeholders into a single room for first time

Expedited design documentation sign off

Agreed dev Team for non CSV will go Agile for Build Phase

Agreed Second dev team to work waterfall in Build Phase

Lead Architect from Dev Team A announced he is leaving the company imminently

Agreed development sequence between the two teams in the build phaseDefault sequence proposed by teams not optimalOutputsA common approach for Build Phase moving forward

Documentation sign off complete - into Build Phase

Progress measured via Burndown Chart (remaining effort) & sprint based working product


Build Phase Synopsis:Maintain daily stand-ups

Working Product Showcased at end of each sprint

Stakeholder confidence skyrocketed

Track progress via Burndown chart - small deviations but tracked closely to plan

Assisted Dev and Test teams with traceability

Maintained requirements for re-use: Minor adjustments to non CSV system result in an edit to project requirements baseline

Managed solution scope and stakeholder expectations: Raised change requests for future releases as needs identified which were not in scope

Identified use of new functionality in discussion with SMEs

Assisted OCM and Test preparations

Exited the Phase on time - but very tight schedule



Agile thinking - using a Burndown chart to measure Demand, Capacity and progress during build phase. 19

Test Phase Synopsis:Extremely nerve wracking Test Phase - lack of defects: High quality or bad testing?

Provided assistance to Test Team and SME in test preparations, incl peer reviews

Test Phases executed with unprecedented lack of defects

Final week of Test Phase used to wrap up project in a pressure free environment

Stakeholders extremely pleased with delivered scope functionality and quality

Project Deployed on time



Wrap up and Review Section21

BABOK technique review22

Business Analysis Planning & Monitoring

Requirements Analysis


Enterprise Analysis

Solution Assessment and Validation

Requirements Management and Communication

Underlying CompetenciesCommenced by assessing the Stakeholders, Roles, Deliverables, created Business Analysis Plan and Performance monitoring, daily calls/ virtual workshops scheduled

Performed requirements analysis on initial prioritisation, extending into elicitation in subsequent iterations - working to define/ verify and validate the requirements and allow dev/ test teams to estimate the aggregate resource demand associated with all requirements

Scheduled/prepared for requirement elicitation sessions, conducted elicitation sessions using Google Hangouts for remote interviews/ workshops, documented in G-docs and confirmed by peer review before qualifying for design activities by development teams

Defined Business Need in first iteration of requirement review and prioritisation

Conducted Org Readiness/ Defined Transition Requirements and triggered actions which led to increase value realisation/ business benefit via training/ comms/ catalogue configuration

Used RMS for formal scope and requirement packaging/ traceability/ testing/ release allocation, G-Documents to communicate/ collaborate on requirements in definition/elicitation process, G-Sheets for scope setting/ project burndown, DMS for formal document sign-offs, daily stand-up and weekly team calls

Used Prototyping, Mockups, Workshopping, Interviews, Systems Analysis, Document Analysis, Problem Solving, Negotiating, Influencing, Conflict Management and multitude of other competencies as Business Analyst in this very challenging project

23Case study: Business Analysis review in BABOK v2 framework


Cherry Picking of the Agile methodologyLike browsing a buffet, we cherry picked applicable aspects of Agile methodologiesWhat we appliedWe estimated and then prioritised requirements from the vast initial list

Business chose a capacity constrained bundle of scope in the project long sprint

We let teams self organised, but we did need to review, challenge and modify the draft plans

We used the burndown concept in conjunction to track progress once scope defined

We had virtual standups to ensure face to face conversations and team motivation

We showed business stakeholders working product during the build phase

Demonstrated real progress and built stakeholder satisfaction

We kept the team motivated and engaged - sense of team from daily standup and weekly TC

Most important: We communicated, did peer reviews, and avoided silos: Despite time and location issues

24The Agile bits we cherry picked


The parts we could not useWelcome changing requirements, even late in development.

Agile processes harness change for the customer's competitive advantage.

The best architectures, requirements, and designs emerge from self-organizing teams.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

The parts we could useDeliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Simplicity--the art of maximizing the amount of work not done--is essential.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

25Agile Manifesto


26Waterfall PrinciplesWaterfall mandatedWaterfall delivery was mandated due to CSV and internal Project Management methodology.Waterfall Phases and deliverables to exit the PhaseProject Initiation: Project Charter, Roles and Responsibilities (PM Deliverables)

Define Phase: Baselined User Requirement Specifications (URS). Baselined Functional Specifications, Baselined Scope *** All essentially BA Deliverables

Design Phase: Draft Design Specifications, Draft Test Plan (Dev and Test Deliverables)

Build Phase: Baselined Design Specifications, Unit Test (complete), Test Plan (signed off), Traceability Matrix (baselined)

Test Phase: Test Report , Deployment PlanProject Value PropositionFollowing Waterfall method was a constraint we had to operate within, which without Agility would have potentially involved high expectations while delivering very little business value

Identifying this constraint early, and being Agile (in thinking and approach) allowed the project to deliver maximum scope and value while navigating the Waterfall gateways.

The Project Manager deserves immense credit for managing the documentation and gateways that allowed the project to be Agile within Waterfall, yet fully compliant and to first manage business expectations, and then exceed these expectations


Business AnalysisactivitiesSet the vision and planned activities to maximise build phase

Influenced Sponsors to focus on their highest priority requirements/ quick wins

Resolved conflicts between stakeholders

Managed and influenced business and project team stakeholder expectation

Overcame time/ distance issues

Collaborated with Operational staff to increase organisational readiness Business Analysis Value PropositionMaximised build phase - each week saved represented 10% of eventual scope!

Deliver those scope items that offer maximum Business benefit

SME interactions discovered unexpected, but significant business benefits

27Adding Value through Business Analysis


Business Analyst uniquely placed to lead via Pivotal Role by setting the vision - others must followProject Manager support of approach made the implementation of Business Analyst approach possible

Tools and techniques used required buy-in and acceptance from project team

Designing during define phase required Development team agility

Thinking Agile only works if team adopts agile thinking

Peer review concept required teams to break down silo mentality

Business Analysis role in bringing the team togetherBA set out the approach and fine-tuned it with feedback

The approach delivered quick wins and benefits

As the Project progressed, team kept doing what worked and optimised via feedback

28Business Analyst as Project Team enabler


Initial ChallengeAs a project, chose to:Practice Agility As a Business Analyst, chose to:Be a leader and set the visionProject outcomeAs a team, we delivered a text book project, despite overwhelming challenges

We delivered full agreed scope, maximum benefit, on time, and with exceptional quality

A happy and engaged set of sponsors, business stakeholders and project team membersPersonal outcomesA lot of satisfaction and enhanced profile within the client company

Many of the tools and techniques utilised have been a template for future engagements - especially around virtual teams

Demonstrated the value of a Business Analyst to the organisation - stakeholders better informed for hiring and collaborating with BAs in the future



30Final Notes Documenting Requirements is a small part of the Business Analysts role - and does not reflect the value add activities a BA can bring to the Project and Organisation

It is simply one of the many tasks that a Business Analyst may perform.

Our role is to deliver Business Value

What distinguishes BAs as a critical project resource is that we are a :Pivotal role bridgingOperations and Project TeamBusiness and Technical StakeholdersPivotal role in ensuringBusiness Need is defined designed, built and deployedBusiness Value is optimised through scope management

Delivering Value to the Business offers career benefits for the individual BA, and BAs collectively