prioritizing requirements

10
(Professional Business Analyst Training organisation) Prioritizing Requirements

Upload: coepd

Post on 17-Jul-2015

25 views

Category:

Education


0 download

TRANSCRIPT

Page 1: Prioritizing requirements

(Professional Business Analyst Training organisation)

Prioritizing Requirements

Page 2: Prioritizing requirements

Prioritization plays a key role in our daily lives since we have a number of tasks to be performed in the various roles we play. Likewise as a business analyst we should be able to prioritize the requirements we gather from the client. There are various techniques to do so such as MoSCoW Analysis, Timeboxing or Budgeting, Voting, Decision Analysis and Risk Analysis.

Page 3: Prioritizing requirements

We will be looking at the first three in detail.Let us take a look at the MoSCoW technique. The requirements can be categorized into the following:

Must: These are the most crucial requirementsWithout these the final solution will be incomplete.

Page 4: Prioritizing requirements

Should: These are also crucial requirements but there could be workarounds to satisfy these.

Could: These are desirable or "nice to have" requirements. If time permits these will be included in the final solution.

Would/Won't: These will be included in the next release or will be omitted completely.

Page 5: Prioritizing requirements

Traditional BA (Waterfall) Agile BA

Requirements are documented in Use

Cases,Business Requirements, Functional

requirements, UI Specifications, Business Rules.

Requirements are documented in Epics, User

Stories and optionally Business (or Essential) Use

cases.

Focuses on completeness of requirement and

spends time in ensuring the requirement is

unambiguous and has all the details.

Focuses on understanding the problem and being

the domain expert so that s/he can answer

questions from the development team swiftly and

decisively.

Focuses on getting a ‘sign off’ on the requirements.

Focuses on ensuring the requirements meet the

currentbusiness needs, even if it requires

updating them.

Often there is a wall between the BA/Business and

the Development team.

Agile BA (Often called as Product Owner) is part of

the team.

Tends to dictate solutions.

Has to remain in the problem domain, leaving the

development team ‘space’ to explore different

solutions.

Long turnaround. Quick turnaround.

Focus on what the requirements document said. In

other words, output (Artifact) is a well written

thorough requirements document.

Focus on the functionality of the developed

software. In other words, output (Artifact) is the

software that meets thebusiness needs.

This technique is most effective when a group of stakeholders are involved in the discussion.

The requirements priority list would keep evolving when the group keeps discussing and applying this technique iteratively.

Page 6: Prioritizing requirements

Next technique is Timeboxing which is also known as budgeting.There are three approaches in this.

1) All in: The group assigns a duration of time or cost to implement each requirement.

We start with all requirements in the box and remove one-by-one based on the deadlines and budget.

Page 7: Prioritizing requirements

2) All out: The group assigns the duration of time or cost to implement each requirement. All requirements are out of the box and we add these one-by-one until the cost/time limit is reached.

3) Selective: This is a balanced approach. Here we identify the high priority requirements and then add/remove those one-by-one to meet the scheduled time/budget limits.

Page 8: Prioritizing requirements

Another technique is voting. In this a set requirements are distributed to a group of stakeholders and each of them gives a vote to prioritize the distributed requirements.

We can conclude by stating that one of the key skills a good business analyst should have is prioritization of tasks as it would help in minimizing overheads and maximizing the resource utilization.

Page 9: Prioritizing requirements

Must Should Could Would/Won't

Communication

Problem solving ability

Probing

Active listening

Documentation

Think like an end user

Domain knowledge

Analytical skills

Presentation

Planning

Persuasion

Collaborative

Critical thinking

Handle ambiguity

Leadership

Negotiation

Flexibility

Adaptability

Open to learning

Breadth of experience

Culture awareness

Customer service

Escalation

management

Influencing

Below is the MoSCoW analysis for skills of a business analyst.

Must Should Could Would/Won't

Communication

Problem

solving ability

Probing

Active listening

Documentation

Think like an

end user

Domain

knowledge

Analytical skills

Presentation

Planning

Persuasion

Collaborative

Critical thinking

Handle

ambiguity

Leadership

Negotiation

Flexibility

Adaptability

Open to

learning

Breadth of

experience

Culture

awareness

Customer

service

Escalation

management

Influencing

Page 10: Prioritizing requirements