Business Analysis Has a Role in Your Agile Transformation
Receive free IIBA updates and exclusive content!
Agile consists of MVP releases which continuously improve on their ability to satisfy. For example, the team will work to release the minimum required to transport the user from point A to B faster than if the user were walking, as they create a skateboard. After feedback, they refine the backlog and work through stories to produce a scooter. They then repeat the experimentation/refinement/feedback/creation cycle to create other modes of transportation that improve on the ability to meet the user needs, until ultimately the team creates the car.
Version 3 of the BABOK® Guide asks Business Analysis professionals to ‘consider the context of the enterprise in developing a change strategy’. In scaling Agile, the team would need to consider the needs beyond the vehicle that they create – consider the roads, the traffic signs and signals that other teams are creating and that are essential to ensure all parts are successful. Business Analysis has a role to not only create the user stories that form the basis of a team’s product, but also to ensure that the product aligns with the rest of the organization.
Agile and Waterfall Requirements Terminology
Be careful - Agile requirements terms aren’t an exact 1:1 match to Waterfall requirements. Some of the documentation captured in Waterfall projects are replaced by conversations in Agile teams. Use cases, while valuable, are not captured to the same level of detail in Agile teams. High level use cases may instead be used as a starting point for user story conversations, although some of the details may be captured as acceptance criteria.
| Agile | Waterfall | Relationship | Definition |
|---|---|---|---|
| Epic | Business Requirement | Is realized by one or more… | A statement of a goal or objective that can be estimated and has a defined business value to the organization. |
| Capability | Stakeholder Requirement | Is realized by one or more… | A product or service that one or more stakeholders need in order to satisfy the business requirement or epic and has a measurable value to the organization. |
| Feature | Functional Requirement | Is constrained by one or more… | Functionality and information the solution needs to provide stakeholders in order to satisfy the stakeholder requirement and has a specified value to the stakeholders. |
| Enabler | Non-Functional Requirement | N/A | Requirements that define the conditions or constrain the functionality of the solution such as performance, security, accessibility, and availability. |
| User Story | N/A | “A placeholder for a conversation” (Cockburn) | User stories are a useful tool for managing requirements, design, development, and tests. They provide just enough information to coordinate the team and stakeholders as they define requirements, design solutions, and implement them. |
| Task | Activity | One or more per artifact… | Something the delivery team must do to satisfy requirements. |
Source: Transition to Product Delivery, Info-Tech Research Group
Corporate Leader Webinar is one of the benefits of IIBA’s Corporate Program.
Corporate Leaders help select topics that would be beneficial to Business Analysis leaders and their communities. Each quarter features a new topic and speaker. To hear more about IIBA’s Corporate Program and receive the full excerpt, please email corporatemembership@iiba.org.
I want to know more!
To receive the full excerpt now and learn how IIBA’s Global Corporate Program can help your organization get better results from your Agile Analysis initiatives complete the form below.
Reach out to a program manager now.
In case you missed it:
Part 1: Why Scaling Agile is Essential for Your Organization
References:
Info-Tech has done extensive research on Agile and Requirements. Review some of our articles and blueprints (research) below, and reach out to our team to find out how you can access more information:
Agile Skills Don’t Revolve Around Ceremonies and Procedures: They’re About Traits and Values.
Agile Doesn’t Mean No Requirements
BizDevOps Starts with Great Requirements
Implement Agile Practices That Work
Transition to Product Delivery
Build a Better Backlog