Documente Academic
Documente Profesional
Documente Cultură
IIBA-NJ Chapter
13-October-2016
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.
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
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
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
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.
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.
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
Good Requirements drive the overall Backlog health into a well groom
product pipeline.
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*
40
Risk
• User Story are to be assigned risk
41
Questions?
42