Agile Foundations for Business Analysts
Target Audience
This course is specifically designed for professional Business Analysts and those charged with performing Business Analysis on a software team. Project Managers and Software Engineers who need to provide analysis will benefit from this course too.
Participants are expected to have experience undertaking Business Analysis on software development projects
The maximum number of delegates on each course will be limited to 10.
Approach
The course is highly interactive and delegates are encouraged to learn through group exercises.
Instructors
This course will be delivered by Allan Kelly and/or Chris Matts.
Allan Kelly has worked as a software engineer, product manager, development manager and Agile Coach. He is the author of Changing Software Development: Learning to be Agile (Wiley, 2008) as well as numerous journal pieces on Agile development.
Chris Matts is a Programme Manager / Business Analyst specialising in building trading and risk management systems for investment banks. Chris has been using Agile and Lean Software Development Methods since 2003. He has been an active member of the Agile community for many years and has written many articles and given presentations at many international conferences.
Course Objectives
By the end of the course the attendee should understand:
- What Agile software development is and how it differs from traditional software development
- The basics of the main Agile methods: Scrum and XP, plus the relationship of Agile to Lean
- How Agile software projects and teams are organised and the roles on these teams
- Why the role of the Business Analyst in Agile is both essential to, and frequently overlooked on Agile teams
- Tools Business Analysts can use on Agile teams to accelerate delivery, increase business value and ensure teams do the right thing
Course Duration
This course runs for 2 days. On-site clients interested in a more in-depth understanding of Agile may wish to consider extending the course to 3 days.
Course Content
1. Agile & Scrum Overview
1.1 What is Agile software development
1.2 Review of Scrum and Extreme Programming (XP) methods
1.3 The relationship between Agile, Scrum, Lean and other methods
1.4 Benefits of Agile and Scrum
1.5 Empirical processes control
1.6 Agile Manifesto: values and principles
1.7 Self-organizing teams
2. Sprints and Iterations
2.1 Sprint Cycle
2.2 Planning
2.3 Sprint Backlog
2.4 Commitment
2.5 Daily Scrum
2.6 Sprint Reviews
2.7 Retrospectives
2.8 Demonstrations
2.9 Release
2.10 Velocity
2.11 Sprint Goal
2.12 Abnormal Termination
3 Technical Practices
3.1 Test Driven Development (TDD)
3.2 Acceptance Test Driven Development (ATDD)
3.3 Refactoring
3.4 Continuous integration
3.5 Simplicity
3.6 Work breakdown
3.7 Estimation with Planning Poker
4. Management Practices
4.1 Vertical teams
4.2 Quality
4.3 Risk management
4.4 Burn-down and burn-up charts
4.5 Visibility
4.6 Definition of Done
4.7 Continuous improvement “Kaizen”
5. Requirements
5.1 Product Owner role
5.2 Customer involvement
5.3 User Stories: Epics, Features and Tasks
5.4 Story estimation
5.5 Product Backlog
5.6 Prioritisation
6. Roles
6.1 Scrum Master
6.2 Product Owner, Customer and Business Analyst
6.3 Team
6.4 Stakeholders
7. How Agile Affects Business Analysis
7.1 Goal directed projects
7.2 Short iterations and just-in-time analysis
7.3 TDD and model driven analysis
7.4 Communication over documentation
7.5 On-going business analysis
7.6 Up-front QA with Business Analysis
7.7 Business value over requirements or features
8. Tools for Agile Business Analysis
8.1 User Stories and INVEST
8.2 User stories as placeholders
8.3 Prioritisation: MOSCOW rules and Absolute
8.4 Managing backlogs
8.5 Assigning business value
8.6 Real options based investment
Available Courses
This is available as an on-site course only, no public courses are scheduled.
If you would like further information on our courses, or would like to discuss how we can build a course for your organisation using our training modules, please contact us.
-
Surveys suggest only 16% of projects are completed on time and within budget -
94% of projects will have at least one re-start -
The main reason for project failure is incomplete requirements ... -
... and the second biggest reason for project failure is lack of user involvement -
In one form or another approximately 25% of British GDP is spent on projects each year -
Reworking requirements defects on most software development projects costs 40 to 50 percent of total project effort
-
If a requirements defect gets into the live system it will cost you 100 times more to fix it
