## 4.5 Estimation and Prioritisation Agile estimating differs from ‘traditional’ upfront detailed estimates as it incorporates the notion of just enough upfront detail. It balances the effort that should be put in estimating with the amount of information available and the expectations or needs regarding the accuracy of the estimations. PM2-Agile estimation is based on three main concepts. - **Relative Estimate** gives a high-level estimate for the size of a work item, typically measured using a neutral unit such as points. - **Velocity** measures the number of points the Agile Project Core Team (A-PCT) can deliver within an iteration. - **Absolute Estimate** translates the size (measured in points) of a work item into an objective, detailed estimate of effort, typically using the units of Actual Hours. The estimation of effort indicates how much time will take the team to complete a specific work item. Relative Estimates are based on the fact that humans are better at making relative estimations11. Instead of person-hours or person-days to determine the size of a Work Item, PM2-Agile uses points to estimate Work Items in relation with other Work Items. Relative estimates tend to be more accurate as the project progresses and both the problem and the solution becomes clearer to the project team. Team velocity is important to track in terms of planning regular iterations and measuring team performance. Detailed guidance regarding the point-based Agile estimating technique is provided in the Agile Tools and Techniques publication. In addition to estimation, Work Items are prioritised according to the delivery value and their contribution toward achieving project goals. Agreeing on and negotiating the priority of each work item considering the team’s estimates, enables contingency management for these projects. The MoSCoW technique for example (‘Must have’, ‘Should have’, ‘Could have’, and ‘Won’t have’ this time) empowers the team to make decisions collaboratively and consciously on what constitutes the ‘minimum usable subset’ or ‘minimum viable product’. Some methodologies suggest that 60% of the total effort should be assigned to the ‘Must have’ requirements, 20% to the ‘Should have’ requirements, and 20% on the ‘Could have’ requirements. Thus, in cases when ‘Should have’ and the ‘Could have’ Work Items cannot be tackled in the specified time frame, contingency is ‘applied’ by still delivering what were agreed to be the most relevant features of the information system – the ‘Must have’ requirements. Both estimating and prioritising are Work Items that should happen continuously throughout the project. Therefore, as the project progresses, the plan on how to achieve the desired goals can be better adapted.