Effective Business Analysis in a Changing World

EFFECTIVE BUSINESS ANALYSISDevFacto Webinar SeriesApril 2, 2015

• DevFacto Consultant

• Over 10 years development, architecture, and software delivery experience

PRESENTER: CHEYNEY WAGNER

THIS PRESENTATION WILL NOT INCLUDE ANY GROUNDBREAKING INSIGHTS. IT WILL NOT

PRETEND TO INTRODUCE THE AUDIENCE TO ANY FORMAL METHODOLOGY. IT IS MEANT AS AN

INTRODUCTION TO LEAN AND APPROACHABLE BUSINESS ANALYSIS ANYONE CAN INCORPORATE

INTO THEIR PROJECT.

HowMethods. Also, who?

WhatWhat to write down

WhyCan’t we just get to development? 1

2

3

EFFECTIVE BUSINESS ANALYSIS

WHY

• Stakeholders know what they want.

• We know how to build it.

• Can’t we just get to it?

The rhetorical question slide

WHAT IS SOFTWARE QUALITY?You need to know what it is in order to deliver it

Suitability

Lack of faults (bugs)

Performance, availability, resilience

?

QUALITY IMPROVEMENT

REQUEST VS TRUE BENEFIT

• What a stakeholder initially asks for may not be what you should build

• Stakeholder requests are influenced by:• Old software/processes/habits• Assumptions about what’s possible• Miscommunication between departments• …

• Business analysis (or business system analysis) determines the functional design of software

• It is more than the translation of stakeholder requests to requirements and specifications

• It incorporates business improvement

• Business analysis is a necessary activity to deliver quality




2

3


Who does business analysis?

BUSINESS ANALYSIS: ROLE OR SHARED DUTYTwo different approaches to performing business analysis

Who

Where

What

Traditional BA Role

• Dedicated team member

• IT departments• Traditional consulting companies• Waterfall projects

• Help define scope & requirements• Communication conduit between

stakeholders and developers• Produce design documentation to

hand-off to developers• Represent stakeholders in project

team discussions

Agile Business Analysis

• Every developer

• Small agile teams (by choice)• Lone-wolf engagements (by

necessity)

• Many of the same analysis activities, without unnecessary communication overhead

• Directly assess impact on code• Barely good enough documentation

STAKEHOLDERS

CustomerSatisfaction

ContinuousIntegration

Unit TestsDeployments

Screens

Database

Performance

Batch Jobs

ORM

Design Patterns

User Experience

Marketing BusinessCases

Training Policies &Procedures Maintainability

Source Control

Security

Code Quality

Language &Dev Tools

Old Tools

DepartmentProductivity

DEVELOPERSBUSINESS ANALYSIS

EmployeeRetention

CONSIDER THIS A CONTINUUMIt’s not necessarily one approach or the other

AgileTraditional

Most developers do “their own” analysis

One or two developers specialize in analysis and help the entire team

Part-time dedicated business analyst shares analysis duties with developers

Team members with the title “business analyst” exclusively decide functional design

ANALYSIS

• Co-location with stakeholders?

• Degree of project politics

• Disposition & availability of stakeholders

• Disposition of developers

• Degree of non-functional complexity

• Client methodology / documentation standards

• …

PROJECT VARIABLES INFLUENCE APPROACH

CONSIDER MOVING TOWARD AGILE

AgileTraditional

• Holistic sense of ownership• Tighter feedback loops / better

collaboration• No communication bottlenecks• More resource redundancy• Decisions made by those with up-to-

date technology expertise

How is effective business analysis done?

Start with WhySimon Sinek’s golden circle

HOW & WHAT

Understand Current State

DetailedDesign

“As an [actor] I want [action]

so that [achievement]”

Screen mockups

Data model sketches

Flowcharts (processes,

navigation, logic)

Use cases

Business rules

Examples / volume estimates / sanity

checks

HOW WHAT

ModelingUser Stories

Stakeholder interviews

Use existing systems

Review data repositories

WHY

UNDERSTAND CURRENT STATE


DetailedDesign



Screen mockups

Data model sketches


navigation, logic)

Use cases

Business rules


checks





HOW WHAT

WHY

UNDERSTAND THE CURRENT STATE

• Review existing documentation

• Use existing systems, examine existing data repositories

• Stakeholder interviews / job shadowing

Don’t make assumptions & know what you’re up against

STAKEHOLDER INTERVIEWS

• Same room > webcam > phone

• Walk through current business processes

• Challenge stakeholders by continually asking Why

Aim for THOROUGH understanding

STAKEHOLDER INTERVIEWS

• Resist the urge to “think like a developer” – understand how the business really works, not how you would like it to work

• Think critically, don’t be critical

• Distinguish between urgent and important

Avoid pitfalls

USER STORIES


DetailedDesign



Screen mockups

Data model sketches


navigation, logic)

Use cases

Business rules

Examples / volume est`imates / sanity

checks





HOW WHAT

WHY

USER STORIES

• Establish scope and drive work.• To-do list• Sprint planning

• Define what, but put focus on who (how) and why

Why

USER STORIES

High level requirement

The intranet must allow employees to view their search history

User Story 1

As an employee I want to view my intranet search history so I can retrace past successful searches

User Story 2

As an employee I want to view my intranet search history so I can remind myself what I was working on last week in order to fill out my timesheet

Why via example

USER STORIES

• Write cooperatively with stakeholders

• Use simple, inclusive tools• Index cards• Projector and word processor

• Pass 1: keep them simple. They’ll be fleshed out later

• Don’t forget non-functional considerations

How

USER STORIES

• “As an [actor] I want [action] so that [achievement]”

• Similar to high level requirements

• Include priority and relative estimate

What

MODELING


DetailedDesign



Screen mockups

Data model sketches


navigation, logic)

Use cases

Business rules


checks





HOW WHAT

WHY

MODELING

• Optimize functional design

• Maximize team understanding

• Maximize return on time investment

Why

MODELING

• Stakeholder involvement is necessary

• Include other developers and testers

• Unpack user stories

• Focus on achievement (Why)

How

MODELING

• Simple, inclusive modeling tools• Whiteboards• projector & word processor

• Inclusive modeling methods• Screen sketches• Flowcharts• Simple data models or data tables

• Examples, examples, examples

How

MODELING

• Shared understanding

• Informal artifacts• Pictures of whiteboards• Shared word processor notes• Examples• Questions / homework

• Fleshed-out detail on user stories

What




2

3


DETAILED DESIGN


DetailedDesign



Screen mockups

Data model sketches


navigation, logic)

Use cases

Business rules


checks





HOW WHAT

WHY

USE CASES

• Documented sequence of interactions between actors (most typically a user and the system) which achieve a goal• Title• Preconditions• Postconditions• Steps• Alternate Steps

• Formalization of flowcharts conceived during modeling

BUSINESS RULES

• Data or access constraints, calculation rules, or programmable policies• No payments can be made more than 60 days after an account’s

termination date• Administration fees will be billed at a rate of $2.00 for every month in

which an account was active for more than 5 days• Customer service staff cannot modify the notes on a case after it has

been escalated to a manager

• Documented not just to facilitate development, but testing and maintenance

MISCELLANEOUS DOCUMENTATION

• Illustrative examples

• Sanity-check statements

• Data volume estimates

• Pseudo code

• Identify logic reuse (e.g. between reports and screens)

Inherent rounding problems & how to deal with them• Whenever you take an aggregate monetary that includes GST and try to retroactively break it apart into subtotals, there is a risk of

rounding problems. This is due to the facts that the true subtotal amounts before GST may include fractions of a cent, but monetary amounts are displayed with only two decimal places.o For example, say this school jurisdiction has two groups - X and Yo X has a total of 13 member months, and Y has a total of 7 member monthso We are calculating based on an admin fee of $2.25 / member / montho GST is separated and rounding occurs at the group sub-total level, not at the grand total levelo GST is separated by subtracting the ROUNDED GST-exclusive subtotal from the totals, NOT by subtracting the un-rounded GST-

exclusive sub-total from the total and then rounding the result.o Correct calculation:

• Group X sub-total with GST: 13 * 2.25 = 29.25• Group X sub-total GST-exclusive: 29.25 / 1.05 = 27.8571 ~= 27.86 <= CORRECT rounding here• Group X GST amount: 29.25 - 27.86 = 1.39• Group Y sub-total with GST: 9 * 2.25 = 20.25• Group Y sub-total GST-exclusive: 20.25 / 1.05 = 19.2857 ~= 19.29 <= CORRECT rounding here• Group Y GST amount: 20.25 - 19.29 = 0.96• Grand total with GST: 29.25 + 20.25 = 49.5• Grand total GST-exclusive: 27.86 + 19.29 = $47.15 <= CORRECT• Total GST amount: 1.39 + 0.96 = 2.35 <= CORRECT GST calculated by adding GST amounts from each group, each

calculated through subtraction• Total GST amount: 49.50 - 47.15 = 2.35 <= CORRECT #2 GST calculated by grand total subtraction

o Incorrect calculation:• Group X sub-total with GST: 13 * 2.25 = 29.25• Group X sub-total GST-exclusive: 29.25 / 1.05 = 27.8571 ~= 27.86• Group Y sub-total with GST: 9 * 2.25 = 20.25• Group Y sub-total GST-exclusive: 20.25 / 1.05 = 19.2857 ~= 19.29• Grand total with GST: 29.25 + 20.25 = 49.50• Grand total GST-exclusive: 49.50 / 1.05 = 47.1429 ~= $47.14 <== INCORRECT rounding here• Total GST amount: 49.50 - (49.50 / 1.05) = 2.3571 ~= $2.36 <== INCORRECT rounding here

EXAMPLE

EXAMPLE

EXAMPLE

Expected Number of Invoices• There are 59 groups who have accounts (i.e. 59 distinct groups will

receive one or more invoices this fiscal year)• Some of these 59 groups have subgroups attached to plan options with

different billing frequencies (for example 619 has 7 subgroups which are billed annually and 1 which is billed quarterly)

• Of these 59 groups, 46 have at least one subgroup which is attached to a plan option which bills quarterly. This means there will be 46 invoices sent out in Januaryo Additionally, there are 12 groups which have at least one subgroup

which is billed annually ando 9 groups which have at least one subgroup which is billed semi-

annually• So the total number of invoices sent in a year will be:

o (46 * 5) + (9 * 2) + (12 * 1) = 260 invoices for 2014-2015

DEVFACTO CAN HELP

DevFacto applies lean, modern practices to any sized software project to deliver innovation and value

devfacto.com

THANK YOUQuestions and Review

Cheyney WagnerConsultant

Contact Us

[email protected](877) 323-3832

http://virtualgoodsinsider.com/




Effective Business Analysis in a Changing World

Data & Analytics

Transcript of Effective Business Analysis in a Changing World