agile business analysis - developing product … in agile software development ... enterprise agile...
TRANSCRIPT
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