a day in the life of an agile business · pdf filelife of an agile business analyst ... review...

Shahriar Maghami

A Day in the Life of an Agile Business Analyst

bbc 2016 Building Business Capability

Identifying the Best Path Forward?

Going Fishing?!

Going to the Moon?!

Agile Suitability Criteria

Technology

Req

uire

men

ts

Suitable for Phased Approach

Suitable for Agile Approach

Unknown

Uncertain, Complex

Anarchy

Predictable

Unk

now

n

known


Adapted from Balancing Agility and Discipline - B. Boehm, R. Turner – 2004

CRITERIA PHASED / PREDICTIVE AGILEComplexity/Uncertainty Low to medium High (but not chaotic)

Predictable Yes No

Requirements Known upfront More known “just in time”

Large Project Size/Timeline Suitable if predictive Suitable

Modern Language & Technology Possible More suitable

Legacy & Mainframe More suitable More challenging due to interdependencies

Data intensive Interfaces Less suitable More suitable

Continuous Change Not suitable Very suitable

Release Management Better streamlined More Adaptive to Business Needs

Infrastructure Projects More suitable More challenging

Sponsor Buy-in Important More important/Critical

Stakeholder /User Time Commitment and Collaboration Necessary Crucial, feedback integral to the process

Maintenance/Production Support Suitable for more predictive/defined projects

In multiple cycles until completion


Adapted in part by independent experience and in part from Suitability Scorecard for Agile Development – Corporate Executive Board and other sources

Review By PM, Agile Expert, BA, SA, or a higher

Committee

Start

High Level Architecture

Analysis

High Level Business Analysis

RequirementsHigh Level

Solution Selection

Assess based on the Best Fit Delivery Method Criteria

Agile: Best fit?

No

Yes

Choose Waterfall

Phase Driven

Choose Agile

Determination of Methodology

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals & interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more

Agile Software Development Manifesto

Producing Adaptive Artifacts

• Create a high level Product Backlog

• Create a high level Project Roadmap

• Break Roadmap into Annual Roadmaps

• Map Releases at a high level onto the Annual Roadmap

• Map high level Product Backlog Items onto Releases

• Give more clarity to more immediate Release

• Map next few Iterations (Sprints) onto associated Releases, covering certain PBIs, in each Iteration

Q1

Release

Q3

Release

Q4

Release

Q2

Release

SPR1 SPR2 SPR3 SPR4 SPR5 SPR6 SPR7 SPR8 SPR9 SPR10 SPR11 SPR12

ANNUAL PROJECT ROADMAP

• Follow Agile Manifesto and Principles

• Combine Traditional Phases, as much as possible

• Just in Time Analysis, Design, Implementation, Testing, Deployment, need to be included in iterations

Practicing Core Agile

Analysis Requirements

Design

Implementation

Testing

Deployment and Maintenance

EndStart

Iteration 1 Iteration 2 Iteration n

Iterative Gradual Completion of the Product

Iteration 3

• Actively participate in Daily Stand Ups • Provide updates on Requirements gathering

efforts, particularly, “just in time” Requirements

• Carefully listen to developers’ updates on their difficulties and successes on Requirements and turning them onto a working software

Attend Daily Stand Up

• Prepare a high level Product Backlog that defines the product

• Continuously work on Product Backlog Refinement

• Update Product Backlog Items, as they get developed and get completed (“Done”),

in-progress, cancelled, or added • Prepare draft of next one or two iteration

(Sprint) Backlog

Prepare and Contribute to Product Backlog

Produ

ct Ba

cklog

• Present the draft of next iteration (Sprint) Backlog to the team

• Take notes of the team feedback on each PBI, discussed

• Contribute to better definition of each user story (PBI), its Definition of Done, and Acceptance Criteria

• Contribute in prioritization of PBIs

• Contribute in estimation of PBIs

Prepare and Contribute to Pre-Planning

Iterat

ion/S

print

Back

log

• Present the upcoming iteration’s backlog • Contribute to better definition of each user

story (PBI), its Definition of Done, and Acceptance Criteria

• Contribute in prioritization of selected PBIs • Contribute in estimation of selected PBIs • Finalize next iteration (Sprint) backlog

Contribute to Planning Meeting

• Each User Story needs to be estimated, on the level of Effort needed to have it completed.

• Estimation effort takes place during a Pre-Planning Meeting or as part of a Planning Meeting, before the start of a working iteration.

• The Team is involved in the estimation effort. The Agile Business Analyst, participates and helps in this process.

• There are several effective methods of estimation: Shirt Sizing, and Fibonacci series used in playing poker estimation, are two of the famous methods.

• Participate in estimation of size/effort, required to complete each selected PBI

• Contribute on breaking each PBI onto smaller PBIs, if necessary, so they can get completed, in one iteration

Contribute to Use Story Size Estimation

Agile/Scrum Lifecycle

Enterprise Analysis

Product Backlog

Sprint Backlog

Sprint

Just in Time Requirements Analysis

and SA & V

Shippable Product

1 – 4 weeks

24 hrs

Elicitation

Business Analysis in Agile/Scrum Lifecycle

Adapted from IIBA Agile Extension to BABOK Guide with some changes

▪ The techniques of business analysis do not change dramatically in the agile environment. But the timing, how they are used, and the extent of documentation, do change.

▪ Agile business analysis is about ensuring the right information is available to the development team in the right level of detail, at the right time, so they can build the right product [“fit for purpose” and “as needed” documentation].

▪ Documentation and artifacts that are more quickly developed such as diagrams, maps, and lists tend to provide more value in agile.

▪ Lower-fidelity artifacts are developed for the sole purpose of building the software for a specific iteration.

BA Techniques, their Timing and Extent

IIBA Agile Extension to BABOK Guide

• Business Analysis Planning and Monitoring ▪ Plan Business Analysis Approach ▪ Conduct Stakeholder Analysis ▪ Plan Business Analysis Activities ▪ Plan Business Analysis Communication ▪ Plan Requirements Management Process ▪ Manage Business Analysis Performance

▪ Elicitation ▪ Prepare for Elicitation ▪ Conduct Elicitation Activity ▪ Document Elicitation Results ▪ Confirm Elicitation Results

▪ Requirements Management and Communication ▪ Manage Solution Scope and Requirements ▪ Manage Requirements Traceability ▪ Maintain Requirements for Reuse ▪ Prepare requirements Package ▪ Communicate Requirements

Many of business analysis techniques described in the BABOK Guide continue to be usable in agile.

▪ Enterprise Analysis ▪ Define Business Need ▪ Access Capability Gaps ▪ Determine Solution Approach ▪ Define Solution Scope ▪ Define Business Case

▪ Requirements Analysis ▪ Prioritize Requirements ▪ Organize requirements ▪ Specify and Model Requirements ▪ Define Assumptions and Constraints ▪ Verify Requirements ▪ Validate Requirements

▪ Solution Assessment and Validation ▪ Assess Proposed Solution ▪ Allocate Requirements ▪ Assess organizational Readiness ▪ Define Transition requirements ▪ Validate Solution ▪ Evaluate Solution Performance

Common Business Analysis Techniques


Agile Techniques Supporting Fund. Principles

Principles of Agile Business AnalysisDISCOVERY FRAMEWORK DELIVERY FRAMEWORK

See the Whole Think as a Customer

Analyze to Determine

What is Valuable

Get Real Using Examples

Understand What is Doable

Stimulate Collaboration and

Continuous Improvement

Avoid Waste

Business Capability Analysis

Personals

Value Streaming

Story Decomposition

Story Elaboration

Story mapping

User Story

Storyboarding

Backlog Management

Business Value Definition

Kano Analysis

MoSCoW Prioritization

Purpose Alignment Model

Behavior Driven Development

Relative Estimation

Planning Workshop

Real Options

Collaborative Games

Retrospectives

Lightweight Documentation


BABOK GUIDE AREA IIBA’s AGILE TECHNIQUESBusiness Analysis Planning and Monitoring

Backlog Management, planning Workshop, Real Options, Retrospectives, Personas, Value Stream mapping

Elicitation Personas, User Story, Story Mapping, Behavior Driven Development, Collaborative Games, Retrospectives, Lightweight Documentation

Requirements Management and Communication

Backlog Management, User Story, Story Decomposition, Story Mapping, Planning Workshop

Enterprise Analysis Business Capability Analysis, Collaborative Games, Purpose Alignment Model, Story Decomposition, Story Mapping, Kano Analysis, Purpose Alignment Model, Real Options

Requirements Analysis Backlog Management, Kano Analysis, Planning Workshop, Personas, user Story, Story Decomposition, Story Mapping, Storyboarding, Behavior Driven Development, Retrospectives, Lightweight Documentation

Solution Assessment and Validation

Real Options, Story Decomposition, User Story, Business Analysis capability, Value Stream Mapping, Retrospectives.

Agile Techniques Mapped to BABOK


Traditional Change Management

Identify Enhancements

Submit Change Request

Review and Assess the Request

Implement Change

Update Requirements / Project Plan

Execute Change Test Change

Approved?

Validated?

End

No

No

Yes

Yes

• The vision and high level scope of the “Product” needs to be reflected on a “Product Backlog” in Agile.

• Product Backlog Items should reflect the most current views of the end users and stakeholders, through continuous collaboration with them and based on their feedback on what has been delivered already.

• Product Backlog Items need to be prioritized. • While we don’t want to start with the vision of a car as the “product”,

then end up with a “house”, we can, and we should allow for changes in the initial scope, within the context of the initial high level scope.

Continuously Mapping Scope Change on Product Backlog

See the Whole and the Big Picture

Integration of Pieces and Their compatibility within High Level Scope

vs

Development Lifecycle

× × × × ×

×

√ √ √ √

√

Early Frame/ Scope

Mid-work Frame/ Scope

Final Frame/ Scope

√ × Feature / Functionality Added Removed

Manage Scope Change in Agile:

Product Backlog Refinement

Product Backlog Refined & Reprioritized Product Backlog

Added PBIs

Removed PBIs

Continuous

Refinement and

Prioritization

Continuously Mapping Scope Change on Product Backlog

Product Backlog Refinement

Epi

c an

d H

igh

Leve

l Use

r Sto

ry D

evel

opm

ent

Affi

nity

and

Dep

ende

ncy

Det

erm

inat

ion

MoS

CoW

Prio

ritiz

atio

n

Hig

h le

vel S

izin

g an

d es

timat

ion

Bre

akin

g D

own

Epi

cs a

nd L

arge

Use

r Sto

ries

Def

inin

g U

ser A

ccep

tanc

e C

riter

ia b

efor

e S

prin

ts

Stakeholder Input on Product

Backlog

Team Input on Product Backlog

Bugs / Defects

Un-finished

User Stories

Development & Refinement of Product Backlog

Product Backlog

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• Individuals & interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more

Agile Software Development Manifesto

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

• 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

• 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

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

• 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

• 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

• 7. Working software is the primary measure of progress.

• 8. Agile processes promote sustainable development. Sponsors, developers, users should be able to maintain a constant pace indefinitely.

• 9. Continuous attention to technical excellence and good design enhances agility.

• 10. Simplicity–the art of maximizing the amount of work not done–is essential.

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

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

Principles of Agile Manifesto








• 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.





Customer Satisfaction













Welcoming Changing Requirements













Frequently Delivering Working Software













Business and Developers Working Together













Build with Motivated Individuals













Face to Face Communication













Working Software













Sustainable Development













Attention to Technical Excellence













Maximizing the Work Not Done




• 4. Business people and developers must work together daily throughout the project. • 5. Build projects around motivated individuals. Give them the environment and support they

need, and trust them to get the job done. • 6. The most efficient and effective method of conveying information to and within a

development team is face-to-face conversation. • 7. Working software is the primary measure of progress. • 8. Agile processes promote sustainable development. The sponsors, developers, and users should

be able to maintain a constant pace indefinitely. • 9. Continuous attention to technical excellence and good design enhances agility. • 10. Simplicity–the art of maximizing the amount of work not done–is essential.



Self Organizing Team













Reflect on How to become Effective

• In traditional approach, scope changes could directly result in changes in delivery time and cost.

• In Agile, working with Fixed Time and Cost is more possible, by focusing on delivering the highest priority add value items, within the same time and cost constraints.

More Value Add with the same Time and Cost

Scope/Feature Set

CostTime

Cost

Scope/Feature Set

Time

Fixed

Variable

AgilePredictive

Increasing Success for Agile

Standish Group, Chaos Report (2002 – 2010)

• Agile Manifesto – Jeff Sutherland, Ken Schwaber, Kent Beck, Mike Beedle, Arie van Bennekum, James Grenning, Jim Highsmith, Andrew Hunt, Robert C. Martin, Steve Mellor, Alistair Cockburn, Ward Cunningham, Martin Fowler, Ron Jeffries, Jon Kern, Brian Marick, Dave Thomas

• Suitability Scorecard for Agile Development - Corporate Executive Board (CEB) – http://www.cebglobal.com

• Strategic Thinking in Complex Problem Solving – Rice University – Arnaud Chevallier – Associate vice provost working on strategic thinking applied to complex problem solving

• BABOK Guide v2 and v3 - IIBA

• Agile Extension to BABOK Guide – IIBA

• Standish Group, Chaos Report

• The Scrum Guide – Ken Schwaber and Jeff Sutherland

• SHAHRIAR MAGHAMI: • www.agiletoday.org • [email protected] • Twitter: @sgmaghami at www.twitter.com/sgmaghami

References

http://www.cebglobal.com/

a day in the life of an agile business · pdf filelife of an agile business analyst ... review...

Documents