Managing and Reporting Agile Projects

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.

About 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.

Tagged , , , , , , . Bookmark the permalink.

One Response to Managing and Reporting Agile Projects

  1. Pingback: What Drives Quality: Project Management | Ben Linders

Leave a Reply

Your email address will not be published. Required fields are marked *

  • Ben Linders – Independent Consultant Agile, Lean, Quality, and Continuous Improvement

    Ben Linders
    Ik help organisaties om effectiever software te ontwikkelen. Neem contact op voor mijn diensten.

    I help organizations to effectively develop software. Contact me to hear about my services.
  • Games and Books

    • Agile Self-assessment Game 9.99 (Excluding VAT)
    • What Drives Quality (eBook) 8.99 (Excluding VAT)
    • Getting Value out of Agile Retrospectives (eBook) 8.99 (Excluding VAT)
    • Business Agility Expansion Pack for Agile Self-assessment game 1.99 (Excluding VAT)
    • Waardevolle Agile Retrospectives (Paperback) 14.05 (Excluding VAT)
    • Agile Self-assessment Game - Polish edition 9.99 (Excluding VAT)