This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
The Agile Project Manager
Agile and Scrum methodologies are helping software organizations stay competitive by delivering products more frequently and with significantly higher quality. Making the switch to agile development also challenges traditional notions of project management, introducing new ways of managing time, cost and scope.
Agile Project Management Explained
Agile project management begins with the premise that software projects are unpredictable and that market uncertainty is going to drive change. Market uncertainty implies that requirements will need to change over the life of the project, and the more uncertain the project is, the more the organization should plan to adapt. For these reasons, uncertainty makes scope an inadequate starting point to begin assessing project performance characteristics.
Instead, agile development projects elevate time and cost as the primary constraints, which are often established before the scope is deﬁned. Rather than beginning to schedule development with an assessment of project scope, the project stakeholders assess the time and money they are willing to invest to bring a product to market. Agile project requirements are written as thin vertical slices of the overall system and constructed in such a way that they are mostly independent, which allows them to be prioritized and implemented in any order.
Writing requirements in smaller, stand-alone increments is critical to varying scope with minimal impact to the project team. Agile teams begin to measure how fast they are able to complete thin vertical slices of functionality and therefore understand how much of the requirements can be delivered within the project time and cost constraints.
Agile Project Scheduling
Agile Project Managers are concerned with two primary performance indicators on an agile project: backlog size and velocity.
The Product Backlog is the list of requirements for an agile project. It represents a prioritized collection of features ready to be built by the project team. Backlog items are estimated in ideal hours, ideal days or more abstract units such as story points. The sum total of these estimates, regardless of unit, is the total size of the backlog. Project Velocity measures how much backlog the team was able to deliver in a given iteration. Velocity can be measured on any consistent time interval and represents the throughput of the team or the rate at which the backlog can be completed. Time to completion is calculated by this simple formula:
Intervals to Complete Project = Backlog Size/Estimate per Interval
Ideal velocity describes the rate at which the team must complete features to deliver the project within the time and cost constraints determined by the project stakeholders. Actual velocity is determined by measuring the true throughput of the team during each time interval. The difference between the ideal velocity and the measured velocity is a primary indicator of how well the project is progressing relative to the expectations of the business. The closer the measured velocity is to the ideal velocity, the more likely the project will deliver the entire backlog within the time allowed.
Agile teams with predictable velocity can reasonably calculate when they will fully deliver the project backlog. If time and cost are ﬁxed constraints, they can determine what features can be delivered within those constraints. Teams with unstable velocities are not predictable and typically result in varying project outcomes. Measuring team velocity over time allows the Project Manager to understand how likely various project outcomes might be to occur.