1. What is BA?
3 definitions
Wikipedia
IIBA
AIBA
o
o
o
o
o
o
o
o
o
Research discipline
Identifying business needs
Determine solutions for business progress
Set of task and techniques
Used to work as a liason between stakeholders
In order to understand structure, process and operation
Recommend solutions to enable the organisation to achieve their
goals
o Effective BA capability
o Drives successful project execution and organizational
performance indicator
Often IT domain
BA can be effective
o Consider much wider perspectives
o Encompasses the organisation (the way it is going)
Agile ba
o
Increasing business value to stakeholders of the project/product being developed.
BA & competencies
Organizational impact
Process improvement
System
improvement
Requirement
elicitation
Analysis and
validation
Requirement
documentation and
management
y-axis: impact on org
x-axis : BA seniority
needed competencies
Problem solving and critical thinking
Behavioral characteristics
Business knowledge
Process modelling
Analysis
Redesign and
implementation
Swot
Strategic
objectives
CSF’s
Value chain
Value proposition
Communication skill
Interaction skills
2. What is Agile
3. Common agile approaches
4. BA techniques in agile projects
BA techniques in agile projects
Discovery framework :
o See the whole
o Think as a customer
o Analyse and determine what is valuable
Delivery framework
o Get real using examples
o Understand what is doable
o Stimulate collaboration and continuous improvement
o Avoid waste
Planning levels
o Day
o Iteration
o Release
o Product
o Portfolio
o Strategic
Agile development tema primarily focus on day, iterations and release.
BA is involved in product planning and contribute towards portfolio and strategic planning.
5. See the whole
6. Think as a customer
7. What is of value
Backlog management
Product backlog
o
o
o
o
Initiated at start of an agile project
Sophisticated to do-list à items/candidates for inclusion.
Items remain on backlog until selected or no longer relevant.
Content
o Anything relevant to the products development.
o Ordered by business value.
Responsible for backlog
o
PO
o
o
Grooming
▪ Add new items
▪ Remove delivered items.
o BL items
▪ Constant review and revision.
During project progress
o Pull from BL for development in progress
o
o
Most important items are likely to be next in line for development
▪ Team identifies task
▪ Estimate effort required to capture them
▪ Details emerge from conversation
▪ Document at meetings.
Items of value always on top
o Focus always on the greatest business value.
Business value definition
o
o
o
Reduce or avoid costs.
Increase revenue
Opportunities to prevent unjustifiable expenditure.
Importance of understanding business value
o
o
o
o
If the work done does NOT increase or protect value of the organisation, erase it.
Do not embark on initiatives
o Without identifying needs or benefits they expect
BA
o Elicitates and articulate business value
o Investigation skills
o Drives valuable analysis
BV definition
o Includes product description and metrics
o Likely source would be a business case for this example.
o Voiced from business perspective
▪ Why and when needed
▪ Can help identify MVP/MMF during release planning
▪ Provide clear focus à valuable discussion.
KANO analysis
o
o
o
Dr. Noriaki Kano
Influenced by two factor motivation theory
o Satisfiers à motivate people
o Hygiene factors à don’t motivate if present.
Product quality can be determined the same way
o 3 attribute categories
basic factors
o Must exist to achieve success
o Improvement will keep customers neutral
o Absence is not tolerated by customers
Performance factor
o Directly correlate to customers satisfaction
o Increased functionality makes customer satisfaction ↑
o If decreased, customer satisfaction ↓ heavily
Excitement factor
o Engender surprise and satisfaction (delighters and exciters)
o Differentiatiors à willing to pay more
Kano questionnaires
o
o
Why à identify requirements that fall into the three categories
2 questions for every feature (group of features).
How do you feel if this feature is present?
How do you feel if this feature is absent?
1
2
3
4
5
I like it that way
I expect it to be that way
Neutral
I can live with it that way
I dislike it that way
Exciter linear must have
indifferent
reject
Moscow
Must
Mandatory
Without there is no reason to implement the product
Should High priority
Must be a part of product
If resources ran out à move to a later part
Could Offer value
Nice to have
Won’t Are of value
Agreed with stakeholders there will be insufficient resources
If recognized
Better design decisions
Allow easier implementation at a latter time
Purpose alignement model
o
Partner
Who cares
Identify and analyse business priority of candidate product features
Differentiating
Parity
1. Differentiating
o Mission critical & high market differentiator
o Attract customers and gain market size
o Differentiation = continually improve and innovate
2. Parity
a. Mission critical but low differentiation
b. Execution of processes à in line with market
c. Too expensive to differentiate on
i.See cost for maintenance with airplanes
3. Partner
a. High market differentiation and low criticality
b. Differentiation is important not critical
c. Could partner with an organization which makes this as high
differentiateable and mission critical
4. Who cares?
a. Low – low
b. Little or no investment.
8. Get real with examples
BDD
o
o
Formal approach to specify products requirements
Giving scenario’s of product behavior from the user’s perspective.
BDD user stories
A formal syntax to write user stories
Scenario
Book review
Given
That I wish to read a review of a book
And
Review exists
When
I ask to see reviews
Then
I can select a review from a list of reviews
And
It will be displayed for me to read.
Creating realistic scenarios:
o Powerful approach
o Stimulates discussion and analysis required to elaborate stories to the level
needed for coding and testing software.
BDD and test automation
o
o
o
o
o
o
o
Test Driven Development
Favours creating tests first and writing codes to meet the tests.
Testing reveals system behavior from customer view point
Easier to define desired system behavior than system tests
In theory , trainied clients can elaborate and create own stories.
BDD provides input to automated testing.
o Powerful addition to agile development approach
Regression testing
o Each new feature that is added
o Ensure that previous parts still work.
9. Understand what is doable
Real options
ROA : Real options analysis
• Financial analysis tool that encourages consideration of alternatives that will
become available as costs of the investment emerge.
• Identify points in the project where option to proceed in various ways will be
available.
• Definition
o Has value
o Expires in time
o Principle: commit to action when you must or when you have enough
information available to decide with clearity.
• Agile teams
o Roa à principle to support planning activities
o One a decision is made, option is lost.
o Wait until LRM (last responsible moment). Never commit until you know
why.
Feature injections
o
o
Begins with business value
Many projects are given requirements that are actually solutions
o This is not considered from business value perspective.
3 steps:
1. Identify value to the business
2. Inject the features (which provide value )
3. Seek examples.
a. Identify value to the business
o
Focus search for business value with demonstratable value that will be returned if
we deliver the requirement.
o Tools to use
o KANO
o
o
o
MoSCoW
Purpose alignment
Others
▪ Boston Box
ROI
SMART ENtity relationship modelling VSM
Enterprise capability management.
b. Inject the features (which provide value )
o
Analyse
o
o
o
Which features deliver requirements?
Team effort
Elaborate à when building phase approaches.
c. Seek examples.
o
o
Feature must ensure required outcome will be delivered
MAIN scenario
o Seek exceptions (f.e. you don’t want a package delivered at 3 in the
morning).
Planning workshops
o
Agile teams plan frequently
o
todays effort, today’s expectation, road blocks
prio stories, estimates, acceptance criteria
MVP, Epic, stories
Release planning
o
o
o
Requirements are not available
Need to produce a reasonable expectation
o What will the product contribute?
▪ When delivered at the end of this release?
Discretion à based on story priority, prioritize, mvp and is driven by business goals.
Iteration planning
o
o
o
o
o
o
Which deliverables will be completed during this iteration?
Enough must be known about backlog items.
o What are they?
o Time to produce.
o BD in tasks.
2 hours
Groom in advance
Acceptance criteria defined and prioritised.
Don via pre-planning.
Relative estimation
Estimations
o
o
o
o
o
Fundamental to planning
Unreliable in early stages of agile project
Easier to compare size than to quantify size.
Development is reluctant to estimate time without having detailed knowledge.
Agile methodology à estimate how big something is relative to other things.
Story points
o
o
o
o
Allocate a value to requirement
Value represents size of the requirement
Generally à smallest story first and compare other stories to it.
Used to make broad estimates.
o
Use Fibonacci numbers à 1,2,3,5,8,13,21,….
o Spreading of Fibonacci numbers
▪ Prevents estimations from fooling with decimals.
Planning poker
o
o
Common used agile technique
Moderator selects a story
o Invites team member to give an estimate
o Discuss scores
o Repeat until consensus is reached.
o
o
o
User story for a dev team à effort to produce a function or feature in software.
Decompose story into tasks to deliver stories.
Everybody is responsible to deliver tasks on time.
Tasks
Velocity
o
o
o
Brings reality to estimating
3 stories at 8 points, but only 2 stories finished = VC: 16
Next iteration planning:
o Estimate more accordingly
o At end of iteration = result time
o Feedback
▪ Fast
▪ Frequent
▪ Unavoidable
Early iterations are hard to estimate. By the 3rd or 4th iteration, a reliable mean would be formed.
10.
Stimulate collaboration and continuous
improvement
Retrospectives
•
•
•
Look back on team’s performance
Formal implementation of continuous improvement principle
End of sprints/iterations/ projects…
Max 1 hr/week (or 1 hr for each week of a sprint).
Structure
1. What did we do well?
a. Start with positive lessons
b. Continue with them à formal lessons.
2. What did we do not so well?
a. How did issues rose?
b. What didn’t we do that we could have done?
3. What lessons have we learnt?
a. What do we take forward to subsequent iterations?
b. What will bring benefit?
4. What do we do to capitalise on what we have learnt?
a. Take actions to reinforce lessons learnt.
Facilitate:
• Participants must have tasks to perform
• With clear deliverables
• Timebox their efforts.
• Vary approaches à don’t let them get used to go with the flow.
Tools of facilitation:
• Brainwriting
•
•
•
•
•
•
Affinity diagramming
Nominal group technique
6 hats
Fishbone diagramming
Mind maps
Post it note exercises.
5 steps to successful retro’s.
1. Set the stage
a. Setup a workshop with an agenda
b. Have every teammember what he/she expects to gain and what he/she will
bring to the meeting.
Post it exercises, brain writing, mind map.
2. Gather data
a. Objective and subjective
b. How feels every team member about their expertise.
c. Highlight issues à trigger a sense of achievement, frustration, distinction.
3. Generate insights
a. Statistical evidence
b. Subjective information à what is the source of success / failure?
c. Group issues
i.Fishbone, affinity diagramming à find patterns and trends.
4. Decide what to do
5. Close retro
• Confirm observations & decisions made
• Provide opportunity à ask questions & clarify
• Ensure complete agreements
• Capture completed work
o Demonstrate value that you place on team’s effort.
Brief retro of retros.
Voice appreciation of team and thank their effort.
Collaborative games
•
•
The whole is greater than the sum of parts.
Replicate common human experience where as a person comes to new and useful
understanding.
• Apply metaphors on parallels to the actual subject under consideration
• Specific objects
• Apply rules
• Lay out rules and maintain focus on outcome.
11.
Avoid waste
Eliminate waste
•
•
•
•
•
Heart of lean
Waste
o Costs ↑
o Profit ↓
Co-locate with team and shareholders
Reduce reliance on e-mail.
Requirements
o
o
o
•
•
•
•
Elicit
Analyse
Specify
Keep models KISS
Pay attention to excellence
Take responsibility for completion.
Make JIT decisions
Lightweight documentation
•
•
•
•
Minimal
Any documentation produced
o Rigourously examined & assessed for waste
o Desirability at a given time.
▪ Maintenance docs
• Produce and deliver when the product is delivered. This
prevents you from making a documentation of a product as
envisaged and delivers documentation as the system is.
Avoid rework
Reduce costs for editing and other activities.