agile analysis techniques by harlan bennett and kevin pious

©2014 CapTech Ventures, Inc. All rights reserved.

©2014 CapTech Ventures, Inc. www.captechventures.com

IT Management ConsulAng Systems IntegraAon Data Management

Agile Techniques for Analysts


Who Knows Agile?

ScrumMaster 46%

Project Manager 16%

Director/VP 15%

Developer 10%

Product Owner 4%

Product Manager

3%

QA 2%

ExecuAves 2%

BA 2%

Source: VersionOne 2013 State of Agile Survey


Agile Analysis Principles

See the Whole

Get Real Using Examples

Understand What is Doable

Think as a Customer

Analyze to Determine What is Valuable

SAmulate CollaboraAon and ConAnuous Improvement

Avoid Waste


See the Whole


Business Capability Analysis

§  Capabili@es are the ability of the business to transform something to help achieve a goal §  Increase revenue §  Reduce cost §  Improve service §  Compliance

§  Agile facilitates frequent reassessment of business needs

§  Teams must maintain a constant view of the business capabili@es


An Outcome

Capability Map

An Outcome An Outcome Performance Gap

Customer Value

Risk •  Business Risk •  Technology Risk •  Organizational Risk •  Market Risk

Business Value

§  Provides a graphic view of elements involved in business capability analysis

§  Shows what capabili@es should be addressed first


Personas

§  Fic@onal characters that exemplify user interac@on §  Help understand value from the standpoint of a par@cular customer

§  Goes deeper than tradi@onal actor descrip@on

•  SoluAons can be prioriAzed based on how well they address the needs of a persona

•  Provides a human “face” to focus empathy

•  Personas can be created that try to embody traits of every user which is not realisAc

•  Not a good subsAtute for a real user


Personas Exercise

Give your persona a name and create their personality and moAvaAon

In your group, create a persona for one of the users of the app

You are working on a project to create a smart phone app for the DC tourism board (washington.org)


Use Concrete Examples

§  Communicate with the team and the customer §  Use the appropriate level of granularity §  Drives

§  Acceptance criteria §  Developer design §  FuncAonal tesAng


Behavior Driven Development

§  Expresses product needs as concrete examples §  As the project progresses examples grow in clarity and detail

§  Examples should be real life business scenarios


How to create a scenario

GIVEN <a context>

WHEN <an event>

THEN <an outcome>

There can be mulAple GIVEN and THEN statements in a scenario, but there should only be one WHEN


Usage Considera@ons

•  Expressed customer need in natural language

•  Supports producAon of effecAve test cases

•  Scenarios can be easily prioriAzed

•  Possible to miss important scenarios

•  Can be too many scenarios if business rules are complex

§  Developers and Testers use the examples to show them what the product needs to do

§  BAs iden@fy the scenarios with the users by asking “what-‐if” ques@ons


Rela@ve Es@ma@on

§  Team ac@vity §  Es@ma@on is con@nuous

§  Accuracy will increase §  Teams will build confidence §  Largely based on points

§  Can be impacted by team changes Project

Release

Sprint

Knowledge Complexity

Size Uncertainty

Story Points


Planning for Delivery

§  Important to think about what is pragma@c and doable

§  Balance capacity and demand

Planning

•  Team pulls top priority work items off backlog and esAmates units of work

Review

•  Product Owner reviews planned work, approves esAmates and authorizes team to execute

ExecuAon

•  Team executes on planned work

Review

•  Product Lead reviews output and determines if Acceptance Criteria have been met


Real Op@ons

§  Helps define when to make the decision §  Three Rules

§  OpAons have value §  OpAons expire §  Never commit early unless you know why

§  Only priori@ze un@l the next investment decision point

§  Determining when the op@ons expire is important


Think as a Customer


Story Elabora@on

§  Lowest level of story decomposi@on §  Just-‐in-‐@me §  Produces the detailed requirements §  Facilita@on skills are key

•  Decreases elicitaAon Ame •  Avoids documenAng requirements that will probably change

•  Can be difficult to determine exactly when to document

•  ElaboraAng the story with enough detail


Story Mapping

§  View of the sequence of ac@vi@es to be supported

§  Usage and Priority §  Connects stories together

User Stories

Epics

Steps

•  Prevents losing the big-‐picture

•  Shows end-‐to-‐end value

•  Hard to do with large products

•  Do not show dependencies between specific requirements


Kano Analysis

Group 1: You are in the market for a $18,000 new car

Group 2: You are in the market for a new smart phone

Group 3: You want to spend a

weekend at a hotel for vacaAon

What are some features that would make you choose one brand over another?


Product Characteris@cs

Threshold • Absolutely necessary • Challenge to elicit

Performance •  Linear increase in saAsfacAon • Easier to elicit

Excitement • DramaAcally increase customer saAsfacAon • Not met by anything currently on the market


MoSCoW Analysis

Must Could

Should Won’t

•  Powerful in prioriAzing backlogs

•  Can be subjecAve if there is not a clear focus on business value


Purpose Alignment Model

§  Assess ideas based on customer and business value §  Rates capabili@es or products in two dimensions

Partner DifferenAaAng

Who Cares? Parity

Market Differentiation

Mission Critical


S@mulate Collabora@on and Con@nuous Improvement


Con@nuous Improvement

§  Product and Process §  Healthy teams rely on trust §  Role of the BA is to create the environment where everyone can contribute value

Retrospec@ve •  What we did well •  What improvements can

we make

•  What could we do beYer •  Focus on the process not

the people


Structured Games

• Construct a box for the product as if it was being sold in a retail store

Product Box

• Write down features on sAcky notes, put them on a wall and move them into themes

Affinity Map

• Divide team into two groups • One group speaks about a topic which others listen and document their observaAons

Fishbowl


Avoid Waste


Ways to Avoid Waste During BA Ac@vi@es

§  Avoid producing documenta@on before it is needed §  Ensure commitments are met §  Make commitments as late as possible §  Elicit, analyze, specify and validate requirements with the same models

§  Models should be as simple as possible §  Close proximity to customers and dev team §  Con@nuous aYen@on to technical excellence


Lightweight documenta@on

§  Documenta@on should not create overhead §  Must create value §  Compliance documenta@on does create value §  Make documenta@on part of the living code base where possible

§  “Working so[ware over extensive documenta@on”


Ques@ons?

See the Whole

Think as a Customer




SAmulate CollaboraAon and ConAnuous Improvement

Avoid Waste

agile analysis techniques by harlan bennett and kevin pious

Technology

vity es

allrightsreser points

state of agile survey

personas fic