AGILE BUSINESS ANALYSIS - developing Product … in Agile Software Development ... Enterprise Agile will drastically change the way you manage your business. – Most management ...

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 Extension3

Waterfall vs. Agile

Source: “The New New Product Development Game” by Takeuchi and 4. Harvard Business Review, January 1986.

Rather than doing all of

one thing at a time...

Requirements Design Code Test

...Scrum teams do a little

of everything all the time

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

Project Noise LevelSource: Strategic Management and

Organizational Dynamics by Ralph

Stacey in Agile Software Development

with Scrum by Ken Schwaber and Mike

Beedle.

11

Agile Manifesto

Process and toolsProcess and toolsIndividuals and

interactions

Individuals and

interactionsover

Following a planFollowing a planResponding to

change

Responding to

changeover

Source: www.agilemanifesto.orgValue the items on the left more, over the items on the right

Comprehensive

documentation

Comprehensive

documentationWorking softwareWorking software over

Contract

negotiation

Contract

negotiation

Customer

collaboration

Customer

collaborationover

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, 201016

7 Misconceptions of Enterprise Agile

• 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.

Source: Blueprint Software systems website

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

Cancel

Gift wrap

Return

Sprint

2-4 weeks

Return

Sprint goal

Sprint

backlogPotentially shippable

product increment

Product

backlog

CouponsGift wrap

Coupons

Cancel

24 hours

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

•Product Owner

•Scrum Master

•Team

3 Roles

•Sprint Planning•Daily Scrum Meeting•Product Backlog Refinement / “Story Time”**•Sprint Review•Sprint Retrospective

4 Events

•Product Backlog•Sprint Backlog•Increment

3 Artifacts

27

Release & Sprint Planning

28

Scrum Roles

29

3 Roles

30

Scrum Team

31

Team Comparison

32

Common Pitfalls

33

Momentum

34

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

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-

Project

Related*

Tiny Extra

Small

Small Medium Large Extra

Large

Huge

40

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.

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