AgilePM Foundation · Domain 7 of 10

AgilePM Foundation Domain 7: Requirements, estimating and prioritisation

How AgilePM handles requirements: the hierarchy from business need to user story, functional and non-functional types, INVEST stories that evolve over time, relative estimating under uncertainty, and the MoSCoW rules.

Exam weight estimate
Not published
Official syllabus topics
3
Estimated questions estimate
~5
Suggested study time estimate
3–4 hrs

About 14 min read Reviewed October 2026

Overview

Requirements, estimating and prioritisation covers how AgilePM decides what to build and in what order. Requirements form a hierarchy, from high-level business needs captured early down to detailed user stories written just before they are built, and include both functional requirements (what the solution does) and non-functional ones (how well it does it, such as performance, security or usability). User stories express needs from a user's point of view and should meet the INVEST criteria; they are refined continually as the team learns.

Estimating in an agile project accepts uncertainty: teams estimate relatively, in ranges, and refine as detail emerges. The centrepiece is MoSCoW prioritisation, which sorts requirements into Must Have, Should Have, Could Have and Won't Have this time. MoSCoW is the mechanism that lets AgilePM fix time, cost and quality and still deliver: lower-priority work is the contingency that absorbs problems.

How it's tested

Expect classification and rule questions: which MoSCoW category a requirement belongs in, what proportion of effort Must Haves should take, which INVEST letter a story fails, or which estimating approach suits an uncertain situation. Read requirement descriptions for clues about workarounds, legality, safety and pain if left out.

  • Classify with MoSCoW

    A requirement and the consequence of leaving it out are described, and you choose Must, Should, Could or Won't Have this time.

  • Rules and proportions

    You apply MoSCoW guidance, such as Must Haves not exceeding about 60% of effort, or what to drop first under pressure.

  • Stories and estimates

    You identify the INVEST criterion a story breaks, a requirement type, or the most suitable way to estimate uncertain work.

Reasoning it through

A question describes a reporting feature the business strongly wants, but says staff could produce the report manually for a few months if it were missing. It is tempting to call it a Must Have because it is important. But a Must Have is one without which the solution is unworkable, unsafe or illegal; a painful requirement with a workaround is a Should Have. Look for the workaround clue.

Syllabus topics 3

Official syllabus topics from the APMG International outline, in outline order.

7.1 Requirements hierarchy and types of requirementFrom high-level business needs to detailed stories; functional and non-functional.
What it means
Requirements are organised from broad to detailed: business needs or objectives, then capabilities or features, then detailed requirements such as user stories. Functional requirements describe what the solution must do; non-functional requirements describe qualities such as performance, security, availability and usability.
What to understand
Early in the project, in Foundations, requirements are captured at a high level and prioritised; detail is added just in time during Development. Non-functional requirements often apply across many features and are easy to forget, so they need explicit attention, often through acceptance criteria or the Definition of Done.
How it shows up
You classify a requirement as functional or non-functional, or decide at what level of detail requirements should exist at a given point in the lifecycle.
Common confusion
Treating 'the page must load in two seconds' as functional because it mentions a page; it describes how well the solution performs, so it is non-functional.
7.2 User stories, INVEST and working with requirements over timeStory format, the INVEST criteria and progressive elaboration.
What it means
A user story describes a need from a user's perspective, often as 'As a [role], I want [goal], so that [benefit]', with acceptance criteria that confirm when it is met. INVEST says a good story is Independent, Negotiable, Valuable, Estimable, Small and Testable.
What to understand
A story is a placeholder for conversation, not a complete specification. Requirements are refined over time: large items are split as they near development, new ones are added, and priorities change, while the high-level scope agreed in Foundations keeps the project anchored.
How it shows up
A poorly written story is shown and you identify which INVEST criterion it fails, or how requirements should evolve during the project.
Common confusion
Thinking a story must be fully detailed when written; 'Negotiable' means details are worked out through conversation.
7.3 Agile estimating, dealing with uncertainty and the MoSCoW rulesRelative, team-based estimates and the four MoSCoW categories with their rules.
What it means
Agile estimating is done by the people who will do the work, usually relatively (for example story points or T-shirt sizes) and with explicit uncertainty, then refined as knowledge grows. MoSCoW sorts requirements into Must Have, Should Have, Could Have and Won't Have this time.
What to understand
Must Haves are the minimum usable subset: without them the solution is unworkable, unsafe or unlawful, or there is no point delivering on the target date. Guidance is that Must Haves take no more than about 60% of effort, with Could Haves (around 20%) as the main contingency. MoSCoW applies at project, increment and timebox levels.
How it shows up
A requirement and its consequences are described and you classify it, or you apply the 60% guideline or the order in which to drop work.
Common confusion
Equating Must Have with 'very important', and Won't Have this time with 'rejected forever'.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • MoSCoW

    A prioritisation technique that sorts requirements into Must Have, Should Have, Could Have and Won't Have this time, so the team knows what to protect and what to drop.

    Remember
    The lower-case o's are only there to make the word pronounceable.
    Tested as
    Central to this area and to fixed time, cost and quality scenarios.
    Trap
    Using it as a ranking of importance rather than of consequence if left out.

  • Must Have

    A requirement without which the solution would be unworkable, unsafe or illegal, or without which there is no point delivering on the target date: the minimum usable subset.

    Remember
    Ask 'what happens if it is not delivered?'; if a workaround exists, it is not a Must.
    Tested as
    Classification questions.
    Trap
    Classifying anything the sponsor feels strongly about as a Must.

  • Should Have

    Important but not vital: leaving it out may be painful, but the solution is still viable, perhaps with a workaround.

    Remember
    The workaround clue points to Should Have.
    Tested as
    Classification questions with a workaround in the stem.
    Trap
    Upgrading it to a Must because the pain is significant.

  • Could Have

    Wanted or desirable but with less impact if left out than a Should Have; the main pool of contingency.

    Remember
    Could Haves are dropped first when the deadline is threatened.
    Tested as
    Questions on what to drop first.
    Trap
    Dropping Should Haves before Could Haves.

  • Won't Have this time

    Requirements agreed to be out of scope for this timeframe, which helps manage expectations and may be reconsidered later.

    Remember
    'This time' matters: it is deferred, not necessarily rejected.
    Tested as
    Definition questions.
    Trap
    Reading it as permanently rejected.

  • 60% Must Have guideline

    Must Haves should take no more than about 60% of the total effort of the project, increment or timebox, leaving room for Shoulds and Coulds.

    Remember
    Too many Musts removes contingency and makes on-time delivery fragile.
    Tested as
    Numeric rule questions.
    Trap
    Choosing 80% or 100%, or applying it to the number of requirements rather than effort.

  • Could Haves as contingency (about 20%)

    DSDM guidance is that roughly 20% of effort should be Could Haves, giving room to absorb problems without touching Musts or Shoulds.

    Remember
    Contingency comes from flexible scope, not from padding estimates.
    Tested as
    Questions on how AgilePM protects deadlines.
    Trap
    Thinking contingency means extra time or money.

  • Functional vs. non-functional requirements

    Functional requirements describe what the solution does; non-functional requirements describe qualities such as performance, security, availability and usability.

    Remember
    Non-functional requirements often span many features and need explicit acceptance criteria.
    Tested as
    Classification questions.
    Trap
    Labelling a response-time target as functional.

  • User story and acceptance criteria

    A short statement of a user's need, typically 'As a role, I want goal, so that benefit', with acceptance criteria that define when it is satisfied.

    Remember
    The story starts a conversation; acceptance criteria make it testable.
    Tested as
    Story-quality questions.
    Trap
    Treating the story text as the whole specification.

  • INVEST

    Good stories are Independent, Negotiable, Valuable, Estimable, Small and Testable.

    Remember
    Know each letter; questions describe a flawed story and ask which letter it fails.
    Tested as
    Story-quality questions.
    Trap
    Expanding N as 'Necessary' or S as 'Specific'.

  • Relative estimating

    Sizing items by comparison with each other, for example in story points or T-shirt sizes, rather than in absolute hours, done by the people doing the work.

    Remember
    Estimates carry uncertainty and are refined as detail emerges.
    Tested as
    Estimating approach questions.
    Trap
    Choosing a single-point estimate imposed by a manager.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Must vs. Should vs. Could vs. Won't Have this time

ConceptMeaningKey differenceCommon trap
Must Have Minimum usable subset Unworkable, unsafe or illegal without it; no workaround Labelling every important item a Must
Should Have Important but not vital Painful to omit, but a workaround exists Upgrading to Must because of the pain
Could Have Desirable, less impact if omitted First to be dropped; main contingency Protecting Coulds ahead of Shoulds
Won't Have this time Agreed out of scope for now Deferred to a later timeframe Treating it as permanently rejected

Functional vs. non-functional requirements

ConceptMeaningKey differenceCommon trap
Functional What the solution does Behaviour or feature, such as 'calculate the refund' Missing quality targets hidden in a feature description
Non-functional How well the solution performs Quality attribute, such as response time or security Forgetting them because they span many features

Relative vs. absolute estimating

ConceptMeaningKey differenceCommon trap
Relative (story points, T-shirt sizes) Size items by comparison with each other Fast, team-based, honest about uncertainty Converting points straight into hours as a commitment
Absolute (hours or days) Estimate the duration of each item directly Looks precise; often falsely so early on Treating early single-point estimates as reliable

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Important means Must

    What candidates pick
    Classify a strongly wanted feature with a manual workaround as a Must Have.
    Why it looks right
    The stem stresses how much the business values it.
    Why it's wrong
    A Must Have is one without which the solution is unworkable, unsafe or illegal; a viable workaround makes it a Should Have.

    Clue to watch for Words such as 'workaround', 'manually' or 'temporarily' in the stem.

  2. Too many Musts

    What candidates pick
    Accept a plan where Must Haves are about 90% of the effort because they are all essential.
    Why it looks right
    It seems to protect what the business needs.
    Why it's wrong
    With no flexible scope left, any problem threatens the deadline; guidance is no more than about 60% Must Have effort.

    Clue to watch for A percentage of effort assigned to Must Haves.

  3. Drop Shoulds first

    What candidates pick
    Remove Should Haves first when the timebox is under pressure.
    Why it looks right
    Shoulds are not Musts, so they seem expendable.
    Why it's wrong
    Could Haves are the primary contingency and are dropped before Should Haves.

    Clue to watch for A question on what to drop first.

  4. Won't means never

    What candidates pick
    Describe Won't Have as requirements the project has rejected.
    Why it looks right
    'Won't' sounds final.
    Why it's wrong
    The category is 'Won't Have this time': agreed out of scope for this timeframe, possibly reconsidered later.

    Clue to watch for A definition question about the W category.

  5. Detailed requirements up front

    What candidates pick
    Write detailed user stories for the whole solution during Foundations.
    Why it looks right
    Detail seems to reduce risk.
    Why it's wrong
    Foundations captures and prioritises requirements at a high level; detail is added during Development, close to when items are built.

    Clue to watch for The question is set in Foundations and mentions detail for everything.

  6. Manager's single-point estimate

    What candidates pick
    Have the Project Manager estimate each story in hours for accuracy.
    Why it looks right
    It looks precise and controlled.
    Why it's wrong
    Estimates are best made by the people doing the work, usually relatively and with explicit uncertainty that narrows over time.

    Clue to watch for A question on who estimates or how to estimate uncertain work.

Answer framework

Use these steps for any requirement, estimate or prioritisation question.

  1. For classification, ask what happens if the requirement is not delivered: unworkable, unsafe or illegal means Must Have; painful with a workaround means Should Have.
  2. Check the proportions: Must Haves no more than about 60% of effort and roughly 20% Could Haves as contingency.
  3. Under pressure, drop Could Haves first, then Should Haves, and protect the Must Haves and the agreed quality level.
  4. For stories, test each INVEST criterion and look for the one the described story fails, such as Testable or Small.
  5. For estimates, prefer relative, team-based estimates with stated uncertainty, refined as detail emerges, over precise single-point figures made early.

Practice question

A requirement is valued highly by the business. If it were not delivered at go-live, staff could use a manual workaround for several months, which would be inconvenient but legal and safe. Using MoSCoW, how should it be classified?

Want more like this? The AgilePM Foundation practice test has questions for every domain.

Checklist

0 of 12

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start with MoSCoW, because it is the area's central technique and links to the fixed time, cost and quality trade-off. Learn the definition of each category as a consequence statement, then practise classifying ten made-up requirements, each with a sentence about what happens if it is missing. Look specifically for workaround, legality and safety clues.

Next, learn the numbers: no more than about 60% of effort as Must Haves and about 20% as Could Haves. Be clear these are effort proportions, not counts of requirements, and that MoSCoW is applied at project, increment and timebox levels.

Then cover requirements and stories. Expand INVEST from memory, and rewrite a few poor stories to fix the letter they fail. Practise sorting requirements into functional and non-functional, paying attention to performance and security statements that hide inside feature descriptions.

Estimating is commonly underestimated. Know why relative, team-based estimates suit uncertain work and how they become more reliable over time.

Afterwards, study planning and control to see how MoSCoW protects timeboxes, and finish with a practice set of classification questions.

FAQ

What does MoSCoW stand for?

Must Have, Should Have, Could Have and Won't Have this time. The lower-case o's are added only to make the acronym readable.

What percentage of effort should Must Haves take?

AgilePM guidance is no more than about 60% of the effort for the project, increment or timebox, so there is flexible scope to absorb problems.

How do I tell a Must Have from a Should Have?

Ask what happens if it is not delivered. If the solution would be unworkable, unsafe or illegal, it is a Must Have. If it is painful but a workaround exists, it is a Should Have.

Does Won't Have mean the requirement is rejected?

No. It means Won't Have this time: agreed out of scope for this timeframe, which manages expectations and allows it to be reconsidered later.

What does INVEST stand for?

Independent, Negotiable, Valuable, Estimable, Small and Testable: the qualities of a well-formed user story.

How detailed should requirements be in Foundations?

High-level and prioritised, enough to understand scope and plan. Detail is elaborated during Development, close to when each item is built.

Who should estimate the work?

The people who will do it, typically using relative techniques that make uncertainty visible and improve as the team learns.

Other Project Management certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 7 knowledge

You have covered the requirements hierarchy, user stories and INVEST, agile estimating and the MoSCoW rules. Check that you can classify requirements correctly from the consequence of leaving them out.

Take the AgilePM Foundation practice test Check your AgilePM Foundation readiness

Keep going