PMP Practice: Continuously assess and refresh team skills to meet project needs

In a hybrid project transitioning to agile execution with an unknown team velocity, the most reliable way to determine resource requirements is to run a pilot sprint or iteration to establish empirical data. This approach allows the team to measure their actual velocity—how much work they can complete in a sprint—which then provides a factual foundation for calculating how many people are needed to deliver the prioritized backlog within the budget and timeline. This is especially critical when the team has never worked together, as estimates without real performance data are highly unreliable. The pilot sprint provides the closing fact needed: actual measured productivity that eliminates guesswork. Once velocity is known, capacity planning becomes straightforward: if the team completes 15 story points per sprint and 120 stories equal 480 points, you can calculate sprints needed and adjust team size accordingly. This empirical approach aligns with agile principles of using real data over speculation and is the standard practice for capacity planning in agile or hybrid environments.

**Why not A:** Creating a resource histogram from the predictive phase plan assumes that the original staffing curve is still valid for agile execution. Since the team has never worked together and velocity is unknown, any staffing model based on pre-existing plans would be speculative and potentially inaccurate.

**Why not B:** Decomposing all 120 user stories into tasks and calculating total person-hours is a bottom-up approach that requires significant upfront effort and produces estimates of uncertain accuracy when the team has no established velocity. This detailed estimation would consume considerable time without the empirical data needed to validate assumptions.

**Why not D:** Benchmarking against industry standards and staffing based on a typical configuration ignores the unique characteristics of this team and product. Industry averages cannot account for the specific team's capabilities, the project's technical complexity, or the particular backlog composition, leading to potentially mismatched resourcing.