Dec
12
Lifecycles in BABOK 2.0
December 12, 2006 |
This is a very early draft of some material that may appear in version 2.0 of the BABOK. I’d like to know if this helps clarify how the BABOK’s tasks and KAs apply to different lifecycles.
Lifecycles
Lifecycles generally impose as few limitations as possible on the nature of the solutions delivered. The focus is on how the project is accomplished, and not what the result of that project is.
Agile Development
Description
Agile development methods seek to:
- Promote rapid and frequent delivery of working software
- Accept and even encourage frequent change in requirements
- Empower team members to make decisions
- Encourage frequent feedback from business stakeholders to the project team
- Minimize the amount of documentation produced describing the solution
Agile lifecycles are predicated on the assumption that stakeholders cannot accurately determine the requirements of a large project up front. Requirements will be incorrect due to change in the organizational environment, change in the understanding of the problem, conflict between requirements, overplanning that leads to implementation of unnecessary features, and so forth. As a result they advocate an exploratory approach to determining requirements, with stakeholders continuously assessing the solution as delivered to date and prioritizing their immediate needs.
The Role of Business Analysis
There are two common approaches to the business analysis role in an agile environment:
- Product Owner: the Business Analyst serves as the member of the project team responsible for assessing and prioritizing all requirements.
- Dispersal: the business analysis role is owned by multiple stakeholders in the project, all of whom are responsible for providing requirements directly to the project team. A member of the project team will take responsibility for planning and management of requirements, and may coach stakeholders to assist them with defining requirements.
Knowledge Areas and Tasks
- Enterprise Analysis falls outside of the scope of most Agile lifecycles.
- Requirements Planning and Management focuses on the prioritization of requirements. Allocation is accomplished through selecting the highest-priority requirements that can be implemented in a single release.
- Requirements Elicitation is performed primarily through discussion with stakeholders and prototyping.
- Requirements Analysis identifies features/scenarios of interest for use in prioritization, and then fleshes those out when they become scheduled for implementation.
- Requirements Communication focuses on informal methods of presenting requirements to stakeholders and the project team. Documentation of requirements is only performed as needed (and may be selected by stakeholders like any other feature).
- Solution Assessment and Validation occurs continuously, as each new release is assessed against the business need and key improvements identified.
Comments
What I'm Reading- Do You really Believe in What you Do?Requirements Defined - Seilevel's Software Requirements Blog
- C.R.A.C.K. Requirements managersBetter Projects
- ‘IT has no inherent value’IT Project Failures
- Business Analysis in an Uncertain EconomyJonathan Babcock
- Why We Lost Focus on Development PracticesAgile Management Blog
- Talking about what we doRequirements Defined - Seilevel's Software Requirements Blog
- BPM is not Software EngineeringGo Flow
- 3 Big CaliberRM Gotchas And How To Fix Them Part 1Requirements Defined - Seilevel's Software Requirements Blog
- Project World and World Congress of Business Analysts (PW&WCBA)Better Projects
- Troubled ProjectsHerding Cats