The document discusses business analysis on Agile teams. It provides an overview of Agile concepts like Scrum and how its roles, artifacts, and meetings work. It also compares traditional analysis approaches to Agile analysis, noting that Agile focuses on just-enough planning, prioritization by the customer, and documenting user stories and acceptance tests versus full specifications.

1. MethodGroup
business analysis specialists
Is a BA required on an Agile
team?
Lucas Murtagh – Lead Business Analyst
MethodGroup – Business Analysis Specialists

2. MethodGroup
business analysis specialists
Agenda

3. Agenda
 Introduction
 Projects
 What are projects?
 How projects work and why some succeed and some fail
 Business Analyst
 What role do BAs perform?
 Good BAs Vs Bad BAs
 Agile Concepts
 So how does agile work?
 Traditional Vs Agile Analysis
 Wrap Up – We need to change our behaviour to become Agile
 Questions?

4. MethodGroup
business analysis specialists
Introduction

5. A little about me
Lucas Murtagh

6. A little about me
Born in 1974

7. A little about me
Lived in the bush for most of my teens

8. A little about me
Studied actuarial & maths at Uni

9. A little about me
Spent first five years of career crunching numbers in
Actuarial and developing complex systems to
understand risk

10. A little about me
Got offered a job as a full time gambler

11. A little about me
Got married and had some kids

12. A little about me
Had to get a real job

13. A little about me
Became a BA…..Real Job!

14. A little about me
Worked on lots of projects

15. A little about me
Across many industries

16. A little about me
Telecommunications
Throroughbred Racing
Mining
Banking
Wealth Management
Insurance
Media
Property
Asset Management

17. A little about me
A variety of subject areas, sizes and complexities

18. A little about me
Some projects went well

19. A little about me
Some projects didn’t go so well

20. MethodGroup

21. MethodGroup
Clear philosophy
Simple
Structured
Collaborative
Industry Aligned
Approach to Business Analysis

22. The world is changing
IT is moving faster than the business
Companies are subscribing to services rather than
building applications

23. The world is changing
What does this mean for us?

24. MethodGroup
business analysis specialists
Projects

25. © 2009 Forrester Research, Inc. Reproduction Prohibited

26. Rusty and Waterfall
 Slow to market
 Documentation is out of date by the time it’s
complete
 Product/Solution is out of date by the time it’s
delivered
 Silo behavior
 May be restricted by what has been agreed in
contracts
 Worker slave relationships within project
It must have some good points….

27. Definition of Project
1. Project:“A temporary endeavor undertaken to create a unique
product, service or result”
2. Has a definite beginning and end
3. Is Unique
4. Consumes resources
5. Starts with an objective

28. Where do Objectives come from (worst
practice)?
 From a senior manager’s posterior
 As a knee-jerk reaction to a media article
 From a big lunch with a supplier
 From something someone said over drinks at a conference
 From the Chairman’s wife not being able to get through to the
call centre
 From the need to be seen to be doing something
 From hearing that’s what they do in the US

29. Where do Objectives come from (best
practice)?
 An efficient business will continually forecast the emerging
threats and opportunities in their market
 An efficient business will continually measure and analyse the
effectiveness of their operation and will thereby identify
opportunities for improvement
 Based on these inputs an efficient business will devise and
maintain an explicit business strategy including strategic
objectives
 An efficient business will identify the programmes of work
required to deliver the strategic objectives
 Project objectives should trace up through programme
objectives to the overall business strategy
 All objectives will be SMART

30. Example of a reasonably clear objective
JFK Stated this one objective in a speech It is Timely, there is time component to
the objective
It was Realistic with Our goal is, before this
the technology decade is out, to send a man It is Measurable,
available at the either the
time (although to the moon and return him
astronaut returns
ambitious) to send a safely to earth alive or he does
man to the moon John F Kennedy not
Congress passed the funding – it was Agreed
SMART!

31. Why Projects Succeed
Project Success Factors % of Responses
1. User Involvement 15.9
2. Executive Management Support 13.9
3. Clear Statement of Requirements 13.0
4. Proper Planning 9.6
5. Realistic Expectations 8.2
6. Smaller Project Milestones 7.7
7. Competent Staff 7.2
8. Ownership 5.3
9. Clear Vision & Objectives 2.9
10. Hard-Working, Focused Staff 2.4
Other 13.9
Source: Standish Group, Chaos report, 2007

32. Why Projects Fail
Project Challenged Factors % of Responses
1. Lack of User Input 12.8%
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%
4. Lack of Executive Support 7.5%
5. Technology Incompetence 7.0%
6. Lack of Resources 6.4%
7. Unrealistic Expectations 5.9%
8. Unclear Objectives 5.3%
9. Unrealistic Time Frames 4.3%
10. New Technology 3.7%
Other 23.0%
Source: Standish Group, Chaos report, 2007

33. Why projects fail – My Experience
 The real problem trying to be solved is not understood
 The solution is agreed before the problem is understood
 There’s no planning. Not just the PM but BAs as well
 People don’t talk
 People infer and assume rather than getting the facts
 Project teams don’t work together to achieve the
goal….SILOS and blame

34. Why projects succeed – My Experience
 Everyone is on the one page and understand the end
goal
 Everyone has a clear role, deliverables and realistic
scope/schedule
 The project team works together. The business, IT
and Vendors are one. Not Silos
 The right skills are on the project

35. MethodGroup
business analysis specialists
Business Analysts

36. BA ROLE IN PROJECTs
Every project team needs:
 Someone who understands the business domain
 Someone who understands how people behave
 Someone who looks at the bigger organizational
problems
 Someone who helps with the management of
artefacts and requirements
 Someone who can help create diagrams/models to
illustrate system working better
 Someone who can help capture learnings and adapt

37. The IIBA defintion
 A business analyst works as a liaison among
stakeholders in order to elicit, analyze, communicate
and validate requirements for changes to business
processes, policies and information systems. The
business analyst understands business problems and
opportunities in the context of the requirements and
recommends solutions that enable the organization to
achieve its goals.

38. What are BAs really doing
 Working in Business and IT projects. Mostly IT.
 90% of the time BAs deliver
 Business Requirements
 Functional/Non Functional Requirements
 Use Cases/ User Stories
 Requirements Traceability
 Process Maps and Procedures
 Data Modelling
 Lots of workshops/1-1 stakeholder interviews
 PA services to PM!!!

39. Good BAs
 Have fantastic written and verbal communication
 Build trusted relationships with Stakeholders and their
team
 Keep all stakeholders on the one page
 Plan their activities
 Have a clear approach to completing deliverables
 Use modelling, benchmarking and reviews to identify
gaps and ensure quality of business needs and solutions
 Don’t over analyse.
 Identify and communicate risks and issues
 Love unraveling ambiguity
 Are proactive

40. Bad BAs
 Write down what the stakeholder tells them to write
down
 Create the requirements themselves rather than
engaging the business. Become SMEs
 Write confusing requirements and define a solution
rather than understanding the business need
 Document to-be processes without testing they will
work
 Sign up to unrealistic deadlines
 Say yes rather than ask why
 Act as a PA rather than BA
 Are reactive

41. MethodGroup
business analysis specialists
Agile Concepts

42. The Agile Philosophy
 Individuals and interactions over processes and tools
 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

43. © 2009 Forrester Research, Inc. Reproduction Prohibited

44. Kate and Agile
 Fast to Market
 Collaborative
 Everyone is clear of what they’re responsible for
delivering
 Team commits to each other
 Continuous review of approach, products and
outcomes
Sounds great but must choose the right project

45. Agile Methods
 SCRUM
 Lean
 XP
Scrum is the most commonly seen

46. Scrum’s 3 + 3 + 3
Three roles
 Product Owner – Describes the Vision. Represents the business and its
stakeholders. BA often perform this role.
 Helps write user stories
 Prioritises the product backlog
 ScrumMaster – Runs the process. Makes sure the team adheres to the rules
 Sounds a bit like a Project Manager
 Development Team – Build the product
 Self organising
 Analyse, Design, Build Test & Train

47. Scrum’s 3 + 3 + 3
Three artifacts
 Product Backlog
 List of the features requirements that need to be delivered
 Provides an overview of the business value and development effort
required to build
 BA play a very important role in helping formulate and prioritizing this list
 Sprint Backlog
 The sprint backlog is the list of work the team must address during the
next sprint.
 Work is not allocated. Team members pick the next task as required
 Can be split up into “Done”, “In Progress” and “To-Do”
 Burndown Chart
 Charts the work remaining in a sprint

48. Scrum’s 3 + 3 + 3
Three Meetings
 Sprint Planning Meeting
 Select what work is to be done
 Prepare the Sprint Backlog that details the time it will take to do that
work, with the entire team
 Identify and communicate how much of the work is likely to be done
during the current sprint
 Daily Scrum Meeting
 What have you done since yesterday?
 What are you planning to do today?
 Do you have any problems that would prevent you from accomplishing
your goal?
 Sprint Review Meeting
 Review the work that was completed and not completed
 Present the completed work to the stakeholders (a.k.a. “the demo”)
 What went well during the sprint? What could be improved in the next
sprint?

49. The Agile Overview

50. Agile works best when
 Project delivery (and ROI) can be incremental
 Core team can be co-located and are dedicated
(business and technology)
 Governance model allows for high visibility and adaptive
planning
 High commitment and availability of stakeholders and
executive sponsors
 Scope and/or High Level Requirements are not stable or
clearly known
 A small team structure which is cross-functionally skilled
is feasible
 Majority of development is on a single system, although
may interface to many
 Project has low external dependencies on vendors or
other projects

51. There are tools to help you confirm your
project is a candidate for agile
http://www.hostfrontier.com/.../008_Agile%20Project%20Selection%20Criteria.xls

52. MethodGroup
business analysis specialists
Agile Analysis Vs Traditional
Analysis

53. Agile Vs Traditional Analysis
Requirements planning activities
Set the stage to gather requirements for the project, identify stakeholders etc.
Traditional
Agile
 Project chartering sessions to  Conduct product vision and
define vision, identify roadmapping workshops
stakeholders etc
 Design and plan release and
 Analyse overall high level plan iteration planning workshops
for project delivery- tasks, time,
delivery dates

54. Agile Vs Traditional Analysis
Requirements elicitation activities
Identify the sources of requirements and then elicit requirements from those sources.
Traditional
Agile
 Plan elicitation techniques  Plan and conduct short
suitable for project and requirements modelling
stakeholders
sessions throughout each
 Plan, design, and conduct iteration
requirements workshops over  identify user acceptance test
weeks/months
data in real-time while story is
being designed/coded/prepare
for testing

55. Agile Vs Traditional Analysis
Requirements analysis activities
Understand and refine requirements further so as to help customer prioritize
Traditional
Agile
 Define full scope up front
 Work with customer, to define
 Develop analysis models for all high-level scope up-front (just-
requirements
enough scope)
 Work with customer to define
user stories and develop
supporting models if-and-when
needed through each iteration
 Customer is responsible for
prioritization based on business
needs and ROI

56. Agile Vs Traditional Analysis
Requirements specification activities
Refine and organise requirements into documentation
Traditional
Agile
 Write a full-blown requirements  Customer and team work
specification document
together to write user stories
 Create user acceptance tests
for each story
 Determine the form and format
of any other documentation
that is necessary and sufficient
for requirements-related work-
in-progress, handover, or
product documentation.

57. Agile Vs Traditional Analysis
Requirements management activities
Monitor the status of requirements and control changes if any
Traditional
Agile
 Smallest necessary requirements
 Write Requirements Management attributes are established for each
Plan
backlog item
 Establish requirements baseline,  Use simple requirements mapping
document change control and organization techniques such
processes and generate as story cards on the wall
requirements traceability matrices
 Changes are considered an
 Conduct change control meetings
important aspect of the Agile
approach and these are
incorporated quite simply as part
of the next iteration

58. MethodGroup
business analysis specialists
WRAP UP

59. Tips to being a great BA in Agile
Work beyond the title of ‘Business Analyst’
 A change in mindset is required- same work, different
tools/format/techniques/physical environment
 Learn to keep the requirements slices to a bare
minimum necessary until it is just about to be
developed
 Connect the development team to the ultimate
sources of business needs
 Get the clients closely involved in the development of
the project
 You are not the sole custodian of all the requirements,
you are part of a self-organizing empowered team
 We need to be more adaptable

60. MethodGroup
business analysis specialists
QUESTIONS?