Skip to content

Managing the Project Management Triangle on an Agile Project

When people find out that I am a proponent of using agile on Microsoft Dynamic projects, they will frequently ask me “How do you manage your project in agile?  Specifically in the area of cost, since you do not know in advance what you are really going to do on an agile project?”

The agile project management triangleThe common misconception with people not familiar with agile is that there is no structure, no controls, no plans, and no management of project constraints on agile projects; people are just doing work in a willy-nilly fashion.   On the contrary, people that have gone from what they consider a “waterfall” approach to an agile approach to managing Dynamics projects, find the just the opposite; people find there is significant project planning, structure, and control in the agile approach.

Under the waterfall approach the scope, budget, schedule are not expected to dramatically deviate from the baseline plan because significant time and effort has gone into discovery and planning.   Change control procedures are normally in effect for waterfall projects, but change is the exception and not the norm.

On an agile project, just as in a waterfall project you still manage the project based upon the three constraints of scope, cost, and schedule.  But what is different from the waterfall approach is the acknowledged expectation and welcomed anticipation that the client’s requirements will change from the project’s baseline during project execution.

What keeps project costs from blowing sky high with frequent scope changes?  The answer lies with the client in the role as product owner.   The product owner’s responsibility is to prioritize the product and release backlogs and determine what and when user stories will go into sprints.   User stories are stakeholder requirements that in aggregate represent the solution scope of the project.  The product backlog is a list of all user story project candidates, while the release backlog represents user stories that have been selected for a release or phase within a project.

Working with the project manager and team, the product owner balances the net effect of scope changes against the constraints of time and budget.   If the goal of the project is to hold fast on the constraints of time and budget, then the product owner must remove user story(s) of equal size from the release backlog in order to balance the constraints.  On the other hand, if the goal of the project is maximize the stakeholder’s requirements on the project, then the product owner is free to add additional user stories to the release backlog, which will potentially increase costs and push out the go-live date.

Managing the project management triangle on an agile project is not much different than what you would find on a waterfall project, with the exception that the client in the role of product owner has control over the solution scope.   The agile concept of the product owner allows the project to retain a sense of agility, while at the same time allowing the management of project constraints; the perfect blend. 

Blog Tags: 
Read ArcherPoint's Blog Follow us on Twitter Follow us on Facebook Follow us on LinkedIn Link to our RSS feed Join us on Google+ Watch us on YouTube