AGILE BUSINESS ANALYSIS -

developing Product Backlog into

Business Capabilities

IIBA-NJ Chapter
13-October-2016

John Werner, PMI-ACP, CSM, CBAP

1
 Agile Defined
• Uses continuous stakeholder feedback to deliver high-quality,
consumable code through user stories and a series of short, stable,
time-boxed iterations.

• Agile is a way to set yourself with the ability to change, all the while
reducing the risk of change.

• Scrum (not SCRUM) is a good framework to enable a high degree of

agility.

From the Scrum Guide:

• Scrum is a framework for developing and sustaining complex
products.
(1991-2011 Ken Schwaber and Jeff Sutherland)

2
Agile Thinking for Business Analysts
Traditional waterfall practices were predicated on
defining everything up front, through a mind-set that:
• At the start of a project the customer can definitely
know, articulate, and define what the outcomes should
be at the end of the project
• Once documented, the requirements will not change
without incurring project delays, budget overruns, or
reduced feature sets.
• The requirements process is confined to a single
functional organizational area that sits apart from the
tem performing the project delivering the product
• Project work is best performed serially, as:
– Define->Build->Test->Deliver->Operate.
Source: IIBA’s BABAK-Agile Extension 3
 Waterfall vs. Agile

Requirements Design Code Test

Rather than doing all of

one thing at a time... ...Scrum teams do a little
of everything all the time

Source: “The New New Product Development Game” by

Takeuchi and 4. Harvard Business Review, January 1986. 4
 An Alternative to Waterfall

Source: Scrumreferencecard.com 5
Value Proposition

6
 Different approaches to risk and
change
On Waterfall projects, risk is manage by:
• Examining requirements in detail until everything
is understood
• Getting those requirements signed off by the
client as the final definition of the project to be
delivered
• Resisting changes to requirements once
development is underway
• Continuing the approach of completing
everything in detail at one stage to be handed
over as a package to the next team downstream
7
 Drawbacks to Waterfall’s approach to
Risk
The world does not remain fixed and by the time
the project is delivered:
• It is no longer fit-for-purpose in the prevailing
environment
• Or there’s lost opportunity waiting for the
project to be delivered

• Both cases result in loss of business value.

8
 Agile reduces business risk
By starting from the assumption that the
circumstances around the project will change,
• Agile practices seek to minimize the impact of
change by delivering smaller parts of the
product more frequently
• Incorporating frequent business review /
feedback
• Readily adapting to and incorporating in
change
9
 Plan Driven vs. Change Driven
• Waterfall practices are driven by highly-
structured plans.
– ‘Plan the work’, and then ‘work the plan’
• Agile practices are driven first and foremost by
delivering viable solutions in incremental
releases that provide discrete business value.
– Effective in leveraging emerging technology,
rapidly responding to changing customer
preference, and dramatically reduce time to
market
10
 Source: Strategic Management and

Project Noise Level Organizational Dynamics by Ralph

Stacey in Agile Software Development
with Scrum by Ken Schwaber and Mike
Beedle.

11
 Agile Manifesto
Individuals and
over Process and tools
interactions
Comprehensive
Working software over
documentation
Customer Contract
over
collaboration negotiation
Responding to
over Following a plan
change
Source: www.agilemanifesto.org
Value the items on the left more, over the items on the right
12
 Individuals and interactions over
processes and tools

• Agile business analysis shifts the focus from

following strict processes and templates to
focusing on helping the delivery team identify
and implement business value.

Source: IIBA BABOK – Agile Extension, 2010

13
Working software over comprehensive
documentation
• Agile practices recognize that there is little
intrinsic value in transitory internal products
that will not be referenced after
implementation. The focus of agile business
analysis is not of delivering perfect documents
to the team, but rather on helping the team
deliver working solutions, based on
incremental just-in-time (JIT) delivery of
requirements.
14
 Customer collaboration over contract
negotiation
• Traditional, a key focus of business analysis
has been to use requirements documents to
gain customer approvals and even signatures.
Agile business analysis addresses this by
producing the minimum responsible
documentation that is developed as late as
possible in the project.

Source: IIBA BABOK – Agile Extension, 2010

15
Responding to change over following a
plan
• On traditional waterfall projects, the big
design up-front effort was then turned into a
plan and the team held to the plan.
• Agile practices delay commitment to the next
work to be performed until the ‘last
responsible moment’, and provides visibility
and transparency for the customer to make
decisions about what to build and when.

Source: IIBA BABOK – Agile Extension, 2010

16
 7 Misconceptions of Enterprise Agile
Source: Blueprint Software systems website
• 1. Enterprise Agile will free you from having to do requirements up front
– Critical discovery and scoping up front are still required.
• 2. You can define business needs with well-defined user stories
– User stories are limited in their ability to provide both ‘big picture’ and granular details
that many business stakeholders require.
• 3. User stories alone are adequate to support compliance and audit
– User stories alone add little value to the enterprise’s ability to meet audit and
compliance requirements.
• 4. Enterprise Agile will drastically change the way you manage your business.
– Most management decisions are the same in Enterprise Agile as they would be using
traditional approaches
• 5. Business Analysis is an “organizational drag”
– Business analysis involves critical, strategic thinking to understand business needs, not
simply the ‘gathering” of requirements.
• 6. Business applications can be understood from code and tests alone
– Code and tests alone aren’t helpful when it comes to understanding ‘why’ certain
applications or components were implemented.
• 7. Enterprise Agile will free you from having to use requirement tools / software.
– Agile doesn’t equal “no requirements”. It should instead be supported by a purpose-
built application configured specifically for agile environments. 17
Why Agile Project Fail?

18
Adoption Barriers

19
 Scrum in about 100 words
• Scrum is an agile process that allows us to focus on delivering the highest
business value in the shortest time.
• A full fledge Agile program may entail delivering solutions in 2 week
increments across 50+ Sprints.
• It allows rapid and repeated inspect of actual working software (every two
weeks to one month).
• The business sets the priorities. Teams self-organize to determine the best
way to deliver the highest priority features.
• Time boxing is a primary driver.
• Every two weeks to a month anyone can see real working software and
decide to release it as is or continue to enhance it for another sprint.
• A “release” is typically when a solution moves from a sandbox environment to
production; it may also be staged into a non production environment to allow for more
intense system integration testing and packaged into a larger deployment.

20
State of Agile 2013

21
 Characteristics
• Self-organizing teams
• Product progresses in a series of “sprints” (max 30
days)
• Requirements are captured as items in a list of
“product backlog”
• No specific engineering practices prescribed
• One of the “agile processes”
• Fail fast!
– (Technical) Spike stories (a Product Backlog Item) often
help determining what is feasible

22
Declaration of Interdependence

Source: www.pmdoi.org
23
 Scrum Life Cycle
24 hours

Sprint
2-4 weeks
Sprint goal
Return
Sprint Potentially shippable
Cancel
Return backlog product increment
Coupons
Gift wrap
Gift
Cancel
wrap Coupons
Product
backlog

24
Putting it all together

25
 Sprints
• Scrum projects make progress in a series of
“Sprints”
– Analogous to eXtreme Programming (XP)
“iterations”
• Typical duration is 2–4 weeks or a calendar
month at most
• A constant duration leads to a better rhythm
• Product is designed, coded, and tested during
the Sprint

26
 Scrum Framework
3 Roles
•Product Owner
•Scrum Master
•Team
4 Events
•Sprint Planning
•Daily Scrum Meeting
•Product Backlog Refinement / “Story
Time”**
•Sprint Review
•Sprint Retrospective

3 Artifacts
•Product Backlog
•Sprint Backlog
•Increment

27
Release & Sprint Planning

28
Scrum Roles

29
3 Roles

30
Scrum Team

31
Team Comparison

32
Common Pitfalls

33
 Momentum

Mass is the Critical Mass of Understanding.

Good Requirements drive the overall Backlog health into a well groom
product pipeline.

Preserving the Momentum is critical to sustain the cadence of the Sprints

34
Daily Stand up

35
Story Decomposition

36
DOD

37
Planning Poker

38
Estimate Scales

39
 Proposed Estimate Scales
0 1 3 5 8 13 21 34
Non- Tiny Extra Small Medium Large Extra Huge
Project Small Large
Related*

Story Points will be assigned at User Story Level

(sub)tasks are assigned in Hours.
Task boundary: 1< Task > 12-16 hours

* 0 Story points do not count toward velocity or burn down.

40
 Risk
• User Story are to be assigned risk

• 1 to 5; where 1 is Low & 5 is high.

– Risk assessment may influence the Prioritization

of the backlog.
– Higher risks may be escalated.

41
Questions?

42