Agile Business Analysis
From MIKE2.0 Methodology
-> You are here: Agile Business Analysis
Agile Business Analysis is not the usual IT business analysis process that happens prior to the development phase. Since the business environment is always changing so are the user requirements in response and the challenge is to keep on accepting the changes and hence deliver the highest value application to the customer. Also when a new application is being built, how does an end-user know exactly what he/she needs when they have never used the application before? The end-user knows what they want beforehand but they will really know what they need once they get some experience using the application. Therefore change is continuous and agility is the key if these applications are to be developed to deliver maximum efficiency and act maybe even as a competitive advantage for a firm. Traditional business analysis thinking is outdated for business software development as it always relied on the hope that all the requirements have been captured to the finest level of detail prior to development and that nothing will change for the next 12 months (or for how long the development and testing will take). Both these premises are invalid, as it is impossible to capture all the details and requirements upfront in a realistic timeframe and the law of diminishing returns kicks in quickly when you are writing requirements for something usually completely new and inexact like business software – unlike when creating architectural analysis of a new building for example.
Agile business analysis is such that it welcomes and enables changing requirements. It is so adaptable (agile) as it is based on a minimalistic principle
– do as much analysis as necessary and not more. It puts paramount emphasis on collaboration between the business customer, other business stakeholders and the whole project team.
The objective of this article is to explain the components of agile business analysis and what is involved. The structure of this document is such that it firstly considers what is good business analysis practice in general
If the project doesn’t create business value, it should be questioned as the assumption of any project should be that it is creating business
High Level Analysis
User Roles, Personas and Goals
High Level Process Maps
Non-functional Requirements Consideration
Need a designer?
High Level User Stories
MECE, Functional Categories and Decomposition.
Change Management Considerations
Training, Communication, other issues…
High Level Estimation
Costs and therefore resource requirements on based velocity and also budget and time to completion.
Prioritisation (cost/benefits), release creation
Low-level User Stories
This is done prior to the iteration.
Breakdown of high level stories
MECE / Dependencies
Iteration Re-planning (based on re-estimation, re-prioritisation and any changes)
Agile Business Transformation is the umbrella article of Agile Business Analysis.
Wiki asset search