Agile for Business Analyst

Agile Business Analysts

Values

• Individuals and interactions over processes and tools.

• Working software over comprehensive documentation.

• Customer collaboration over contract negotiation.

• Responding to change over following a plan.

Principles (12)

1. Our highest priority is to satisfy the client/customer.

2. Welcome changing requirements, even late in development.

3. Business people and developers must work together daily.

4. Agile processes promote sustainable development.

5. Maximize the amount of work not done.

6. Agile aligns you with the customer.

7. Provides flexibility to adapt to market changes.

8. Reduces non-value-added work.

When to Use Agile

• When projects are complex and urgent.

• When it makes sense for the team, organization, and project.

• When there is trust among the team members.

Agile Methodologies

Why We Need Methodologies

• Methodologies provide a structured process for working in Agile environments.

• Principles alone are not enough—Agile requires a common process, roles, practices, artifacts, and a common language.

Scrum

Scrum Roles

• Team: Includes UX Designers, Business Analysts, Developers, etc.

• Product Owner: Responsible for creating and managing features and requirements. The BA may sometimes act as the Product Owner or guide the Product Owner.

• Scrum Master: Facilitates team activities and removes obstacles. BAs are rarely Scrum Masters.

Scrum Practices

• Work is done in 1–4 week iterations (sprints).

• The Product Owner maintains a prioritized backlog.

• The team selects the highest priority work for the sprint.

• Testing occurs as features are built.

• At the end of each sprint, the team delivers a shippable product.

• The Sprint Review allows the team to demonstrate what was built to the Product Owner.

• The Sprint Retrospective helps the team reflect on what went well and identify improvements.

Scrum Artifacts

• User Stories: Descriptions of what the user needs and why.

• Product Backlog: A prioritized wish list of all features and requirements.

• Sprint Backlog: The set of tasks the team has committed to for the current sprint.

Scrum Meetings

• Sprint Planning: What work will be done in this sprint?

• Daily Scrum: Team members report what they did yesterday, what they will do today, and any obstacles.

• Sprint Review: A demonstration of the work completed in the sprint.

• Sprint Retrospective: Reflection on the sprint to improve future performance.

Agile Team Roles

Scrum Team Roles

• Team Members: Developers, testers, designers, and others. They estimate tasks, determine scope, and commit to work.

• Product Owner: Owns the product vision, strategy, and backlog. They may require assistance from the Business Analyst (BA).

• Scrum Master: Facilitates the team's work, removes obstacles, and coordinates with management.

Agile Business Analyst Roles

The Old Challenge

• In early Agile frameworks, there was no defined BA role.

• Some believed BAs were only responsible for documentation, but Agile emphasizes collaboration, not just paperwork.

Defining the BA Role

• The BA’s role evolves based on team needs and organizational structure.

• BAs may work as team members, Product Owner assistants, or even Product Owner proxies, though this last role is not ideal.

BA as Team Member

• Responsibilities:

  • Elaborate user stories.

  • Split stories into smaller tasks.

  • Define acceptance criteria.

  • Manage dependencies.

  • Guide prioritization.

• Focus on delivering value rather than excessive documentation.

BA as Product Owner Assistant

• Supports the Product Owner by helping manage backlog and requirements.

• Acts as an advisor to the Product Owner, but the Product Owner remains responsible for the product vision.

BA as Product Owner Proxy

• In cases where the Product Owner is unavailable or lacks the necessary skills, the BA may step in to make decisions.

• This is challenging, especially for junior BAs, as they lack full decision-making authority.

User Stories

What Are User Stories?

• User stories describe the features a user needs and why.

• Each user story should be:

  • Clear.

  • Attributed to a user.

  • Prioritized.

Writing User Stories

A user story typically follows this format:

As a [type of user], I want [an action] so that [a benefit].

Example:

As a user, I want to see a summary of important information when I log into the marketing portal so that I can immediately understand how everything is going.

Key Points:

• User stories are commitments to have a conversation with the customer.

• Avoid technical jargon; keep stories simple for better understanding.

• Story splitting is key: Break larger tasks into smaller, manageable chunks.

Acceptance Criteria

What Are Acceptance Criteria?

• Acceptance criteria define the conditions that must be met for a user story to be considered complete.

• It outlines the tests or conditions under which the product works as intended.

Writing Acceptance Criteria

Three formats for writing acceptance criteria:

1. Boolean Statement:

   • Example: "The report is sorted by last name (ascending)."

2. "Make Sure That" Format:

   • Example: "Make sure the report is sorted by last name (ascending)."

3. Given-When-Then (Behavior-Driven Development):

   • Example:

     Given the report contains two or more rows,When the user runs the report,Then the report is sorted by last name (ascending).

Epics and Story Splitting

What Are Epics?

• Epics are large, high-level stories that are too big to complete in a single sprint.

How to Manage Epics:

• If a story is too big to complete in one sprint, break it down into smaller user stories.

Story Splitting Example:

• "Blogging Functionality" can be split into smaller tasks:

  • Author a blog post.

  • Publish a blog post.

  • Edit a blog post.

  • Tag a blog post.

Backlogs

Types of Backlogs

• Product Backlog: A list of all features, improvements, and fixes for the product.

• Sprint Backlog: The list of tasks that the team will work on during a particular sprint.

Story Points and Velocity

• Story Points: A relative measure of the effort required to complete a story.

• Velocity: The number of story points the team can deliver in one sprint.

Story Mapping

• Story Mapping is a visual representation of the product backlog.

• Helps to organize user stories by function and priority.

• Used to create sprints and plan upcoming work.

Tools for story mapping:

• PowerPoint

• Excel

• Vision

A Day in the Life of an Agile BA

Typical BA Tasks

• Writing User Stories and Acceptance Criteria.

• Story Splitting and Prioritization.

• Managing the Backlog and Story Map.

• Conducting Stakeholder Interviews.

• Analyzing Gaps and providing solutions.

• Facilitating Team Understanding of requirements.

The Sprint

• A sprint is typically 1-4 weeks long and results in a releasable product.

• Sprint planning involves the Product Owner, Scrum Master, and team members.

The Release

Types of Releases

• Wide Release: Distributed to all customers.

• Pilot Release: Distributed to a subset for feedback.

• Beta Release: Distributed to a subset to identify issues.

Release Planning

• Considerations for release include impact assessment, quality, security, performance, and business needs.

• Effective communication and training are essential during releases.

When to Release:

• Release as soon as possible to minimize unused features (lean principle).

• Understand which features to prioritize for release.