How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

People Requirements

People Requirements are the documented capabilities, capacity, and constraints needed to compose and support the Scrum Team(s) for a product or release. They outline team size, key skills, availability, and conditions such as location or compliance to guide team formation, staffing, and training decisions.

Key Points

  • Input to Form Scrum Team and Identify Scrum Master and Stakeholder(s); often initiated during Create Project Vision and refined in Release Planning.
  • Describes needed capabilities and capacity, not specific names or rigid role titles.
  • Ensures cross-functional coverage required to meet the Definition of Done.
  • Includes availability, dedication level, location and time zone, language, and compliance constraints.
  • Iterative and living document that evolves with the product backlog and release goals.
  • Used by the Product Owner, Scrum Master, and stakeholders to plan staffing, onboarding, and training.

Purpose

Provide a clear, lightweight reference for what people capabilities are needed to deliver valuable increments. Align team composition and capacity with product goals, guide staffing decisions, and surface constraints early so that risks can be addressed before sprinting begins.

In multi-team efforts, help coordinate skills across teams and shared services to avoid bottlenecks and uncovered work.

Key Terms & Clauses

  • Capability set: development, testing, UX, data, DevOps, domain expertise, and any specialized compliance skills.
  • Capacity and dedication: estimated team size, number of teams, and expected full-time commitment per person.
  • Cross-functionality: preference for T-shaped skills to reduce handoffs and increase flexibility.
  • Constraints: time zones, co-location needs, security clearance, tool access, and language requirements.
  • Availability windows: overlap needed for Scrum events and pair/mob work.
  • DoD coverage: confirmation that skills exist to satisfy Definition of Done and critical non-functional requirements.

How to Develop/Evaluate

  1. Review the Product Vision, epics, and key non-functional requirements to understand the delivery scope.
  2. List required capabilities to build, test, integrate, and release potentially shippable increments.
  3. Estimate capacity: target team size and number of teams based on historical velocity or forecasting assumptions.
  4. Capture constraints: dedication level, location and time zone overlap, compliance needs, and tool access.
  5. Validate with the Product Owner, Scrum Master, and key stakeholders (e.g., HR, security, architecture).
  6. Reassess during Release Planning and whenever backlog priorities or constraints materially change.

How to Use

  • Identify Scrum Master and Stakeholder(s): select a Scrum Master with suitable facilitation and domain context and confirm stakeholder groups needed for collaboration.
  • Form Scrum Team: guide staffing, onboarding, and training so the team is cross-functional and dedicated.
  • Release Planning: check whether capacity aligns with release goals; trigger training, hiring, or vendor sourcing if gaps exist.
  • Sprint Planning and ongoing delivery: verify availability changes, adjust scope ordering, and address skill gaps via pairing, mentoring, or targeted coaching.
  • Scaling: coordinate capabilities across multiple teams and define shared services or communities of practice.

Example Snippet

  • Team composition: 1 Product Owner, 1 Scrum Master, 5 Developers (cross-functional), 1 QA automation specialist.
  • Capabilities: backend API, UI, test automation, UX, DevOps, data modeling.
  • Availability: 7 full-time equivalents; minimum 4-hour daily overlap between GMT+1 and GMT-5 for Scrum events.
  • Constraints: access to staging and CI/CD tools; privacy compliance training required within first sprint.
  • Success condition: skills cover Definition of Done including performance and security checks.

Risks & Tips

  • Anti-pattern: listing specific names instead of capabilities leads to rigidity and bottlenecks.
  • Over-specialization creates handoffs; prefer T-shaped team members to maintain flow.
  • Part-time allocations and context switching reduce predictability; aim for dedicated team members.
  • Ignoring non-functional needs (e.g., security) causes rework; include them explicitly.
  • Failing to update People Requirements as the backlog evolves undermines planning accuracy.
  • Use a simple skills matrix to visualize coverage and guide targeted coaching or hiring.

PMP/SCRUM Example Question

During Release Planning, forecasted velocity shows the current single-team setup will not meet the desired release date. The Product Owner asks the Scrum Master how to respond. What is the best action using People Requirements?

  1. Extend the sprint length from 2 weeks to 4 weeks to get more done per sprint.
  2. Update People Requirements to propose a second cross-functional team and identify training or sourcing to cover missing skills.
  3. Add mandatory overtime to increase output without changing team structure.
  4. Add two part-time specialists to the existing team to cover gaps.

Correct Answer: B — Update People Requirements to propose a second cross-functional team and identify training or sourcing to cover missing skills.

Explanation: People Requirements guide capacity and capability decisions; scaling with another cross-functional team and closing skill gaps aligns with Scrum practices better than extending sprints, overtime, or part-time additions.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Launch your career!

HK School of Management provides world-class training in Project Management with AI and Agile Methodologies. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More