XoNgon Blog

Just Another Journey With Flip Flops

[xongon-2]

Scrum Model  - Agile

Project team completes sprints

A short iteration from analysis, development, testing and possibly to deployment of a product (14-30 days long).

Uses a subset of prioritized requirements that form a sprint backlog. Requirements are derived from a product backlog.

The project team is made of Product Owner, Scrum Dev Team, and Scrum Master

Product Owner is responsible for the return on investment (ROI).

Focuses on the requirements, the “what”.

Scrum Dev Team is cross-functional.

Collaborates to build the product each sprint, the “how”.

Scrum Master is the team facilitator, but has no power.

Removes roadblocks, sets timeframes, and provides visibility.

Product Backlog

List of features that the business wants, force ranked by the Product Owner (one #1).

Anyone can add items, could be user stories or use cases.

Does not contain tasks.

Sprint Backlog

Committed features that will be completed within the current sprint.

Has a deadline to complete.

Tasks are tracked as:

Not started

In Progress

Completed

Sprint Planning – Commit items to the sprint backlog.

Daily Scrum – Daily, 15 minutes. Yesterday, today, roadblocks.

Sprint Review – Demonstrate product, get feedback.

Sprint Retrospective – Inspect last sprint. Lessons learned.

Product Backlog Refinement – Adjust, split, and determine dependencies of backlog items.

Pros & Cons

+ Flexible and adaptable to changing requirements.

+ Gets workable product in-front of the business quicker.

+ Promotes collaboration between business and development teams.

+ Daily feedback on progress and roadblocks, stops “spinning wheels”.

- Leads to scope creep due to no defined end date.

- Relies on commitment of all team members.

- Challenging to initially adopt and train in an organization.

- Changing or leaving team members can have a drastically negative effect.

When to Use?

The project is unpredictable and will have changing requirements.

Using or creating leading edge technology.

Organization as an experienced Scrum Master.

Business has experienced resource that can dedicate time to the project.

Pressure to produce a tangible product quickly.

Little to no concerns on length of project or budget.

Development team doesn’t have resource constraints.

Source: The BA Guide - Business Analysis Fundamentals Course

[xongon-2]

Incremental Model

Pros & Cons

+ Provides early value in the development life cycle.

+ Allows for requirement changes between iterations.

+ Problems can be detected earlier.

+ Can utilize knowledge learned in an earlier iteration.

- Heavy documentation, especially around interfaces with other systems.

- Can lose track of the overall business problem.

- Difficult problems tend to get pushed to future iteration.

When to Use?

Requirements of the system are clearly understood.

When demand for an early release of a product arises.

When software engineering team are not very well skilled or trained.

When high-risk features and goals are involved.

Such methodology is more in use for web application and product based companies.

Source: The BA Guide - Business Analysis Fundamentals Course & https://www.guru99.com/what-is-incremental-model-in-sdlc-advantages-disadvantages.html

[xongon-2]

Waterfall Model

Requirements

Business needs analysis.

Elicit and document requirements.

Design

Design solution to meet requirements.

Determine hardware and system requirements.

Split design into segments.

Development

Develop/code each segment based on design.

Developers unit test each segment.

Testing

System test each segment (QA or BA).

User acceptance test each segment (Business).

End-to-end test all segments together as one.

Deployment

Deploy software into production environment or release to market.

Maintenance

Fix bugs with patches/releases.

Enhance the product to meet changing business needs.

Pros & Cons

+ Clear expectations on schedule, budget, and resourcing needs.

+ Extensive documentation helps ensure quality, reliability, and maintainability.

+ Progress is easily measured.

- Inflexible and cumbersome.

- Long pole from project start to something tangible.

- Problems are discovered at user testing.

- Written documentation is never kept up-to-date, loses usefulness.

- Promotes gap between the business users and the development team.

When to use?

Clear objectives and solution.

Large, complicated, and expensive.

No pressure for immediate return on investment (ROI) from implementation.

Project team is fully knowledgeable about the solution application.

Requirements are stable and will be unchanged through development.

Resource constraints.

Strict requirement for formal approvals at milestones.

Source: The BA Guide - Business Analysis Fundamentals Course

[xongon-2]

Example RACI for Assessing Business Need

Consider an insurance company that is interested in reducing the processing times and costs for automobile and homeowner claims. Initially, the organization understands the solution may impact a number of stakeholders across the company. To better understand who to involve in the needs assessment phase, the business analyst develops a RACI matrix to determine the roles and levels of responsibility.

Table below shows an example of a partial stakeholder list for the insurance company. Other possible stakeholders might be the claims operations manager, claims examiners, partners, and suppliers.

Another example:

Source: Business Analysis for Practitioners: A Practice Guide - PMI & https://www.smartsheet.com/comprehensive-project-management-guide-everything-raci

[xongon-2]

Stakeholder Identification

A stakeholder is an individual, group, or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a program or project.

During needs analysis, it is helpful to identify the following stakeholders:

Sponsor who is initiating and responsible for the project.

Stakeholders who will benefit from an improved program or project.

Stakeholders who will articulate and support the financial or other benefits of a solution.

Stakeholders who will use the solution.

Stakeholders whose role and/or activities performed may change as a result of the solution.

Stakeholders who may regulate or otherwise constrain part or all of a potential solution.

Stakeholders who will implement the solution.

Stakeholders who will support the solution.

The affected stakeholders for a needs assessment can be categorized into one of four categories using a responsibility assignment matrix such as a RACI model:

R - Responsible: person performing the needs assessment.

A - Accountable: person(s) who approves the needs assessment, including the business case, when warranted.

C - Consult: person or group to be consulted for input to understand the current problem or opportunity.

I - Inform: person or group who will receive the results of the needs assessment.

Source: Business Analysis for Practitioners: A Practice Guide - PMI & https://www.teamgantt.com/blog/raci-chart-definition-tips-and-example

[xongon-2]

Why Perform Needs Assessments

Needs assessment work is undertaken before program or project work begins, therefore it is said to involve the preproject activities. However, during the course of a project, should external factors change (e.g., corporate merger, large percentage loss of market share etc.), which influence or impact the project in process, the business analyst will need to revisit the needs assessment and decisions made previously to ensure they are still valid for the situation the business is addressing.

A needs assessment involves the completion of a gap analysis - a technique that is used to analyze and compare the actual performance of the organization against the expected or desired performance. Much of the analysis completed during the needs assessment is then used for the development of a business case. It is the needs assessment and business case that build the foundation for determining the project objectives and serve as inputs to a project charter.

Source: Business Analysis for Practitioners: A Practice Guide - PMI

[xongon-2]

Requirement Types

Business Requirements: describe the higher-level needs of the organization as a whole, such as business issues or opportunities, and reasons why a project has been undertaken.

Stakeholder Requirements: describe the needs of a stakeholder or stakeholder group, where the term stakeholder is used broadly to reflect the role of anyone with a material interest in the outcome of an initiative, and could include customers, suppliers, and partners, as well as internal business roles.

Solution Requirements: describe the features, functions, and characteristics of a product, service, or result that will meet the business and stakeholder requirements. Solution requirements are further grouped into functional and nonfunctional requirements.

Functional Requirements: describe the behaviors of the product.

Nonfunctional Requirements: describe the environmental conditions or qualities required for the product to be effective.

Transition Requirements: describe temporary capabilities, such as data conversion and training requirements, and operational changes needed to transition from the current state to the future state.

Source: Business Analysis for Practitioners: A Practice Guide - PMI

[xongon-2]

Definition of Requirement

In the PMBOK® Guide – Fifth Edition, the term requirement is defined as “a condition or capability that is required to be present in a product, service, or result to satisfy a contract or other formally imposed specification.”

A requirement represents something that can be met by a product or service, and can address a need of the business, person, or group of people. A requirement should be independent of the design of the solution that addresses it. A requirement may explain a feature that is to be met by a product or software component. When a specific type of requirement is under discussion, the term requirement is preceded by a qualifier such as stakeholder, business, or solution.

Source: Business Analysis for Practitioners: A Practice Guide - PMI

[xongon-2]

Roles involved in business analysis

Organizations today may find that business analysis is being performed within their organization by one or more of these roles:

Agile team members

Business architects

Business intelligence analysts

Business process analysts

Business subject matter experts

Data, functional, operational, systems, or user experience analysts

Enterprise business analysts

Product managers or product owners

Project managers

Requirements, software requirements, systems, or value engineers

Requirements managers

Source: Business Analysis for Practitioners: A Practice Guide - PMI

[xongon-2]

Skillset and Expertise Needed for the Business Analysis Role

Analytical skills

Business and industry knowledge

Communication skills, including strong business writing and verbal communication skills

Conflict management

Creative and critical thinking

Cultural awareness

Decision making

Facilitation

Familiarity with multiple project and development methodologies

Influence

Issue management skills

Leadership skills

Learning skills

Negotiation skills

Organizational skills

Political awareness

Presentation skills

Problem solving

Systems thinking

Technical awareness

Ability to work effectively in a team environment, including virtual teams

Source: Business Analysis for Practitioners: A Practice Guide - PMI

[xongon-2]

What is Business Analysis?

In short, business analysis is the set of activities performed to identify business needs and recommend relevant solutions; and to elicit, document, and manage requirements.

Source: Business Analysis for Practitioners: A Practice Guide - PMI