Managing and Reporting Agile Projects

Rate this post

Many software development organizations use Prince-2, PMI or some other project management method to manage projects. Most often, IT projects have to be done fixed time, money and scope. How can you do this with the agile approach, that has user stories, planning games, and a flexible scope?

First, fixing time, money and scope is often an illusion. Many IT project fail, resulting in higher costs, insufficient quality or functionality, not meeting the delivery date, or a combination of these. Keeping everything fixed is simply not feasible. With agile, it is easy to manage the project costs and end-date. Project costs are mostly the costs of the project team members, and since the size of the agile teams is known, the burn rate can be calculated. When a delivery date is agreed, it is easy to calculate the project costs that will be spend until that date.

What about managing functionality? Agile uses prioritizing of user stories to deliver the most important functionality first. And since agile teams deliver working software in sprints, and continuously improve their way of working, most agile projects actually deliver more functionality then waterfall projects. Techniques like story points and planning poker are used by agile teams to estimate the activities. The product owner uses the backlog to manage the content of project. When reporting project progress, the agile project manager shows which functionality has been delivered, and (given current priorities) what is expected to be delivered in the reminder of the project. This is different from traditional progress reporting, which is usually based upon milestones or tollgates that are or should be passed. But reporting delivered functionality actually provides better insight in the value delivered to the customers, which makes it easier for project managers and steering groups to manage project results.

Managing projects includes managing the quality of the software. Agile uses the Definition of Done (DoD) to define the required quality of the software. The DoD describes what needs to be done before the software is ready to be delivered, I consider it to be the tailored process description that the team makes and uses to do their work. The acceptance tests, defined during the planning game, state how the software will be validated. Since these acceptance tests are discussed and agreed upon with the product owner, they can also be seen as requirements for the quality of the software.

Summing up, Agile supports managing time, costs, functionality and quality, as required by project management methods.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.