How Business Analyst defines a "business need"?

Here is the short blog on how to how to define the Business Need (either a problem or an Opportunity)

These high level guidelines or parameters will help business analysts defining their Business Needs.

Understand the business:

1.1 Business definition:

Business definition consist of analysis of following information:

1.1.1 What is the 'Entity Type'?
you need to define if the is proprietary or Corporate or Public Limited or Cooperative or Government…
You need to understand what are their governance standards  (such as tax, regulatory process) and requirements. and do they impact on your business need in anyway?

1.1.2 What is the Business Domain?
Is it agriculture or Service, or Hospitality or Defense or  Health Care or Banking or retail or manufacturing, or logistics and so on...

1.2. Products and Services:

1.2.1. Organization Structure (organization units and sub-units and how they are connected to main entity/Head office. People and their association with these entities and their role and position in the organization hierarchy)

1.2.2. Management and its culture (Democratic, lean management, hierarchal, traditional, modern….) Quality policy and standards, quality management process, values and beliefs

1.2.3. Clients, customers and the market: To understand their background and the special needs

1.2.4. Operations and legal and compliance requirement: How the products and services are reached to the end customers?

1.2.5. Organization goals: Long term and short term goals

1.2.6. Core competence: Products and services and other issues. Why these are better selling products compare to their competitors.

1.2.7. Competitive stance: who are competitor and comparison with competitors

1.3. Industry Standards 

  1.3.1 Current Industry Benchmark

  1.3.2 Current and potential future trends in the industry

1.4 New regulations

All these information and data is very useful to analyze the business in comprehensive manner. Without this analysis, the Business Analyst cannot provide the correct business solution that is appropriate the organization.

1.5 Background of Business Need (problem/opportunity):

When we identify the problem or the opportunity we have following area to work on:

1. The Record the problem or opportunity area.

2. Source of the problem or the opportunity:

3. Background of the problem: How it has arisen? Or how the opportunity has been generated.

Impact analysis or identify business value or Business Impact Analysis (BIA):

4.1. Area (department, functions): which part of the organization or which functions are getting affected with business need. For example, the problem is in retrieving sales data for retail chain store, check if the problem is in one region or it is across the region. Or it could be one ‘field’ or some more fields.

4.2. Stakeholders: Who (role – user or customer, signing off authority) are getting affected directly or indirectly? Are there more number of stakeholders is getting impacted with the problem or opportunity. The nature of impact needed to consider before the business need is fully defined. Pls refer stakeholder analysis in planning phase for more details.

4.3. Business Operations: where the impact is? One process or entire business processes are affecting? Is it industry wide impact (example. Change in service tax may affect the pricing and accounting process of the organization. Whereas, implementation of Basel II and Basel III would affect entire banking industry irrespective of size or location).

The best way to approach the problem is to complete the “Gap Analysis” where current business processes are compared against new (required) business processes and the organization’s current and future capability required implementing the same.

5. Financial and non-Financial impact of proposed solution

5.1 Will it increase revenue?

5.2 Will it decrease expenses?

5.3 Will it bring in new customers?

5.4 Will it bring in more money from existing customers?

5.5 Will it improve employee moral?

5.5.1 Not all the problem solving will result into business value such as financial and brand value. Sometime, resolving problem may result into improving the process that result into making things easier for employee in performing their daily work. Repeated work, instant access of data to make decision, decision support system.

5.5.2 Redundant process or lengthy or cumbersome process can be improved to make employees easy to do their daily work without unnecessary hurdles for additional approval or so on. This may result into improved employee moral with additional challenging project/work in their professional life.

6 Brand and image impact: problem within existing products or services or problems related to customers or problems related to operations ie delivery of products / services to the end customers.

6.1 Will it increase shareholder/taxpayer value? Increased customer satisfaction or improved products of services may result into increased revenue. Reduced operations cost could result into increased revenue. Both the cases, there will be direct or indirect impact on shareholder value.

7 Policy, Legal and compliance

7.1 Any new compliance or policy change may result into change in exiting operations or need for new business operations. Either way it may result into need of new business systems.

Once you analyze the business need on above parameters, you will have an understanding of business need and it's impact on the business. This analysis will support the stakeholders to make a decision - go/no-go.

More details in next blog - how to create a business need documents using these parameters and support the solution scope.

Reference:

http://www.uie.com/articles/business_value/

What Business Analyst needs to know about Agile Approach?

Here is the brief blog written on "What Business Analyst need to know about Agile approach?" in Q & A form. It is helpful for you to know about Agile in-depth and will also be helpful in preparing you for your Business Analysis interview. This blog will focus more on Scrum as it is more popular and widely used Agile approach. My next blog will have summary of other Agile approaches.

Please explain - what is Agile.
Agile is an approach to project management that is used in developing software solution. It is group of methodologies based on incremental and iterative approach to help the team to respond to the unpredictability of building a software solution. It also helps the team to explore the solution as requirements continuously evolve through assessment and adaption while producing the software solution through a series of demonstrable, executable releases of product/project.

The process can be custom-made by development or client or organization optionally based on the technical constraint, organizational standards, team’s comfort, or project scope, budget.

The point to remember that every iteration progressively contributes to developing and delivering the solution.

Following are some of the ‘Agile’ methodologies:

· Extreme Programming
· Scrum
· Lean Software Development (LSD)
· Feature Driven Development (FDD)
· Dynamic Systems Development Method (DSDM)
· Agile Unified Process (AUP)
· Adaptive Software Development (ASD)
· Kanban

Scrum is most commonly used Agile approach in the modern IT environment.

What are agile manifesto?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Explain Scrum. How did you use it in your last project?

We used Scrum as it is the most preferred agile framework. We applied in managing and controlling iterative and incremental software solution (projects).

(for additional information: Ken Schwaber, Mike Beedle, Jeff Sutherland and others have contributed considerably to the evolution of Scrum.

The “Scrum’ is derived from rugby game where the ‘scrum’ means of restarting play after a minor infringement.)

We applied common strategies of Agile as follows:

• Sprint consisted of 3-4 weeks that was delivered in the form of workable component or feature.
• Informal communication: It was close interaction among small team (2-12). 
• Light and informal communication: Along with informal communication and informal process were followed. These meeting were frequent and face-to-face to understand the progress from every team members and resolved the issues, if any.
• Change management: was informal and changes were welcome at late stages
• Customer collaboration: Each iteration or sprint was delivered to user to access. The changes or improvement were done during the following release(s).
• Informal Process: Every sprint or iteration was part of product or solution. End of the release the component, the remaining components were assessed and prioritized for the next development. If any new component was added and was found to be important, it was accommodated before other complements were developed depending on the prioritization. This prioritization was part of every post release activity and no changes were added once the Sprint was in the process.
• From technical perspective, every iteration or Sprint was considered as a mini-project that went through entire lifecycle phases (define, requirement analysis, design, development, test and deployment) in compressed and fast paced mode.

What is Product Backlog?

‘Product Backlog’ is a prioritized Backlog containing the end user requirements. It is also a prioritized list of features (requirements or bug fixes, non-functional requirements, etc.) that contains short descriptions of all functionalities desired to be implemented to deliver the working or potentially shippable increments of the software product or solution.

This is used in place of traditional requirement specifications such as BRD (business requirement document) or a product roadmap or SRS (Software Requirement Specification).
The product owner owns the product backlog. Product owner along with cross-functional team estimate and sign off to deliver potentially shippable increments.
Stakeholders and other team members can add stories / features / functionality / requirements to the product backlog in the form of ‘To-Do’ list.
Product backlog is enough to start work in Scrum instead of lengthy formal documentation used in traditional project management approach.

#	User Story	Priority	Estimation
1	As an authorized user, I want to access ‘manage beneficiary’	1	2
2	As an authorized user, I want add a beneficiary	2	3
3	As an authorized user, I want to edit beneficiary	3	1
4	As an authorized user, I want to set transfer limit to the beneficiary	5	1
5	As an authorized user, I want to receive alter on my registered mobile phone after completing the transfer	6	2
	Total		9

• Each story adds a value to the user/customer.
• Each story is prioritized and developed in an order.
• Any team members can add a story and delete (his/her) story at any time during the project life cycle. 
• However, a “Sprint” (or iteration) can’t be changed by adding or removing story. 
• The product backlog is analyzed and re-prioritized after every “Sprint” and based on the prioritization, the stories are selected for development for the next “Sprint”
• The Product backlog is updated during entire project life cycle.
• All stories are estimated.
• All the stories are complete within and no low level tasks are added in the product backlog.

What do you understand the term ‘an epic’ in an agile project?

There are many requirements scattered across the multiple areas of the complex solution or product. The segregation and grouping of the User Stories belonging to the same domain is known as ‘an Epic’. An Epic is complete when all the User Stories are added and concluded.

What is the User Story in Agile?

A User Story is a requirement / feature / functionality described in the form of a story. User Story explains ‘who’, ‘what’ and ‘why’ of a particular requirement.

For example: As an authorized user, I want to access ‘manage beneficiary’ to add the new beneficiary.

This will define:

Who - authorized user,

What - access ‘the manage beneficiary’ functionality,

Why - to add the beneficiary

During the life cycle, these user stories are identified, prioritized, and selected for a Sprint for implementing. They are further specified into tasks, estimations and other details related to tasks.

What is Sprint?

Sprint is an iteration or basic unit of scrum approach. It is typically consist of 3-4 weeks or 30 days. Software solution / software product is delivered through successive sprints.

What is a sprint backlog?

Similar to Product backlog, a sprint backlog is a list of features and requirements that team shall achieve in the next sprint. It is based on requirements priority and development team’s ability to complete the work.

What is the sprint-planning meeting?

The sprint meeting is conducted at the beginning of every sprint. The product owner, scrum master, and development team member(s) meet to understand the capability of the team, create the ‘sprint backlog’ by prioritizing the items, plan and delegate the work for the sprint. Although some mention 8 hours required for the sprint-planning meeting, but, there can’t be a fixed duration of the same as the components may not take same duration to discuss and finalize.

What is Daily Scrum Meeting?

As name indicates, these are short terms strategies. Every day during the sprint, the team assembles to discuss the progress of the sprint and strategy, if necessary. It is short (average 15 min long) and informal that can be even done at the team member’s desk.

Each member in turn answers three questions:

1. What did I do since the last Scrum meeting?

2. What do I plan on doing between now and the next Scrum meeting?

3. Do I have any roadblocks?

What is Scrum (Kanban) Board? What is a ‘Story Board’?

This board represents the progress in the ‘Agile’ approach.

You can create virtual or manual story board by placing note on each section.

The column indicates the stage and row indicates the User Story/task in a particular stage.

This is an excellent way to represent the status of the User Stories/tasks along with the project.

Design	Development	QA Testing	UAT	Deployment	Done
Task L	Task H	Task E	Task C	Task B	Task A
Task M	Task I	Task F	Task D
Task N	Task J	Task G
Task O	Task K
Task O

Or

Product Backlog	In Sprint (Development)	Delivered
Task F	Task C	Task A
Task G	Task D	Task B
Task H	Task E
Task I

Explain Sprint Review Meeting.

At the end of sprint or on the last day of the ‘Sprint’, there are two ‘sprint review meetings’ – one for customer review and demonstrations and other for team to review for the possible improvements. The adequate time is allowed (some can calculate by deriving the value from.

The duration of the meetings may vary. For each week of sprint duration, apply one hour of meeting time for the customer review. For the retrospective, apply .75 hours (45 minutes) for each week of Sprint duration. For example, a 30-day Sprint would result in a four-hour review and three hour retrospective. A two weeks Sprint would result in a two hour review and a one-and-a-half hour retrospective. Additionally, the team should spend no more than one hour preparing for the review.

These are the meetings that review - what was achieved in the course of the sprint and what is left.

What is Sprint Retrospective (meeting)?

Team members analyze the past sprints to understand the "lesson learned"  from the previous project to avoid similar mistakes and improve continuously.

What is Scrum Framework?

It outlines broad guidelines for scrum projects with few rules (dos and don't), roles (Product owner, Scrum master, scrum team), artifacts (deliverables or prioritized backlog) and events (Scrum Planning Meeting, Scrum Meeting, Sprint Review Meeting etc.) to deliver a software solution or products via iterative, interactive, and incremental approach.

This framework provides guideline for the role, nature of customer collaboration, communication.

It works on a principle of:

- Continuous improvements - inspect & adapt policy to engineering processes, product, and requirements.

- Change Management – is an integral part of project life cycle.

Thus, the framework allows defining only high-level requirements at beginning and low-level requirements at later stage/during implementation.

Communication: Scrum Product Owner collaborates with scrum master and scrum team to identify and prioritize the user stories/functionalities.

Why do we use a sprint burn-down chart?

It is graphical presentation of the progress of the sprint that is updated daily during the sprint.

Explain the Scrum Team and their role?

Scrum Team comprises of Product Owner, Scrum Master and the Development Team.

Product Owner:

Product Owner is a primary stakeholder of the software product/solution. He works intently with the team to create product backlog by identifying, adding, modifying and prioritizing the user stories.

Scrum Master:

Scrum Master works as a facilitator to the project team. He manages resources, enforces the scrum rules on the team, lead the scrum meeting, and guide the team as required.

Scrum Team:

The team decides what and how much they can do in a given project iteration or a Sprint. The team is responsible for developing and delivering the sprint.


What the term ‘Spike’ in scrum?

Spikes are time bound planned activities or sessions between the Sprints created for analyzing or answering queries.

What is the Velocity of a sprint?

It is the capability of the team to complete the work during a particular Sprint that is derived from analyzing the historical data.

What is ‘Tracer Bullet’?

The ‘Tracer Bullet’ is a ‘Spike’ or analyzing session using latest technology, latest architecture and latest best practices in the industry to produce top quality product.

What do you know about ‘Impediment’?

Impediments are ‘the causes’, which are hindering the team or team member to achieve their goals or maximum capability.

What do you mean by ‘ScrumBag’?

‘ScrumBag’ is the person or group or any factor responsible for ‘Impediment’.

Do you know ‘Invest’ in Scrum?
‘Invest’ suggests the characteristics of a good ‘User Story’ based on following criteria:

Autonomous: No other ‘User Story’ is depending on.

Zero-Trade-Off – No further negotiation required for this

Value – User Story brings in sizable value to the end product.

Scalability – The User Story can fit various sizes easily

Testability – It is testable to verify the success criteria of implementation of the User Story.

What is Planning Poker?
It is bringing consensus among the team on estimation of a particular User Story during planning phase.

Planning Poker Cards are distributed to the team members. Each card has a number that is associated with estimations in the form of either hours or days. Once a User Story is selected, every team member is asked to display their card that conveys their estimation for that User Story. If all the cards display the same number, that number (estimation) is finalized as ‘estimation’ for the User Story.

In case the cards displayed have different numbers for a User Story, estimations are discussed and finalized by brining everyone on an agreeable term.

Reference: 

1. Agile Estimation and Planning by Mike Cohn

2. Scrum Institute 

(http://www.scrum-institute.org)