MoSCoW Prioritization

The analysis of the priority of requirements for a project, can be defined through a technique called MoSCoW Prioritization.

The requirements are divided into the states of :

1. Must have : Fundamental requirements
2. Should have : Important but not vital
3. Could Haves : "Nice to haves"
4. Won't have : Features taht are absolute pointless

Define and Prioritize :

1. List key requirements
2. Understand importance of each
3. Estimate time and cost

3 important variables for requirements :

1. Time
2. Cost
3. Quality
4. Scope/Requirement

Product Manager is expected to understand the requirements and communicate them to proper stakeholders

Project Manager

1. Discuss goals
2. Get clarification
3. Create list of requirements
4. Meet goals

Senior Operations Manager

1. Provides high-level requirements
2. Has operational knowledge
3. Responsible for defining requirements
4. Identify values
5. Connect project managers to users

Product Owner

1. Subject Matter Expert
2. Understands user needs
3. Provide a greater level of detail
4. Closely engaged
5. Authority to define requirements
6. Authority to prioritize
7. Involved with testing

Development Team

1. Creates the products
2. Conducts testing

Results are clearly defined through the following considerations :

1. Products to produce
2. Quality criteria
3. Work involved
4. Who to involve

Feasibility, Definition, Incremental delivery stages

User Story too capture requirement

The 3 C

Conversation, Card, Confirmation

INVEST : Independent, Negotiable, Valuable, Estimable, Small, Testable

Functional

What it must do? How it must behave?

Non-Functional

How well it must perform? How will it work?

Sprint Tracking

What have you done?
What will you do?
Are there any blockers?

Reasons for changing a project

1. Requests
2. Product failure
3. Evolving Solution
4. New approach or technique
5. Change in external environment

Changes in Breadth

1. Additional high level requirement
2. Impacts time or cost
3. Requires approval from project sponsor

Changes in Depth

1. Minor changes to low-level requirements
2. Does not impact time or cost
3. Approved by the team
4. Recorded on the project board

Basline requirements

1. Capture version numbers
2. Records changes as new versions
3. Compares current to earlier versions

Impact of no Baselining

1. Morre development time and efforts
2. Dependent products may not work together