Delivering Agile Projects using Microsoft Project/Project Online

Agile (or Iterative development) projects have become mainstream development and require project management tools to support effective delivery management.  And while there are many excellent Agile-specific tools in the marketplace, adapting an Agile-specific tool adds to the number of environments, licenses and training required in your organization.  In this article, we explore extending Microsoft Project and Project Online/Server with custom fields, filters, views and macros to support the requirements of Agile management while preserving your organization’s current investment in the Microsoft PPM toolset.

Related WebNLearn: Integrating Agile Projects into Microsoft Project/Project Server

Agile Overview

Agile development is based on the principle of developing the final product incrementally through a series of short development cycles of 2-4 weeks (iterations).  This enables the business and the team to better understand the scope and effort of each iteration and therefore be more successful with “on-time, on-budget” delivery of each iteration.  In addition, because the final product is developed incrementally, there is more opportunity to validate the results of each iteration and refine and improve the solution through the yet-to-be planned future iterations.

But in order to ensure that the Agile project achieves the desired business goals, there are a series of Agile principles (often called Rituals) that should be applied:

  • Project/Product Vision – This is a brief but critical upfront planning session to outline the overall objectives for the project.  The Vision is important as it is constantly referenced to ensure that all work being completed in each iteration is consistent with the project vision.
  • Release Planning – While short development iterations of 2-4 weeks are the core principle in Agile, most projects combine a number of iterations into a release to allow for packaging and implementation of the product at regular and valuable intervals.  Therefore, a brief planning sessions is required to define the objectives, content and duration of a release.  Then during the iterations, the Release Plan is used as a reference to ensure that all work is consistent with the Release Plan (very similar to the Vision, except that the Release Plan satisfies a smaller component of the overall Vision).
  • Iteration Planning – The Iteration (or Sprint) is the core of Agile.  All development is completed within the Sprints, and each Sprint should deliver final code which is complete and implementation ready.  The Iteration plan identifies the work (Stories) which can be completed within the iteration and validates that each story is consistent with both the release plan and product vision.
  • Product Backlog – The Product Backlog is the repository for all Stories that are to be completed by the project.  The Product Backlog requires ongoing attention from the Product Owner to ensure that it accurately represents the current set of stories which achieve the Product Vision.  Product Backlog maintenance allows the Product Owner to effectively change the identified stories to ensure the project evolves to meet the refined business requirements.
  • Iteration and Daily Scrum – The Daily Scrum is a brief (15 minute) meeting where the team reviews the current status of the iteration and validates that the story development in the iteration remains on track to be fully completed according to the iteration plan.
  • Agile Reports – A series of very detailed reports (typically called BurnDown Charts) are produced on a daily basis to track progress on stories and work completed versus the amount remaining for the current iteration.

In this article we will review how all these principles are delivered with using Microsoft Project and Project Server/Online.

Agile Reports

Burndown/Burnup charts are a core component of successful Agile management.  Using the reporting functionality in Microsoft Project 2013, a full suite of reports can be created to allow for the validation of the work at an Iteration, Release or Project level.  These reports provide you with the information needed to review and understand the progress being made on completing the stories and satisfying the requirements of the Iteration and the Release Plans as you progress to satisfying the overall project vision.

Agile Sprint Burndown Example
Agile Sprint Work Down Example

A full suite of burndown/burnup charts can be created to report on progress within the sprint based on the story count or hours worked.  These reports are focused specifically on the work required for completing stories and therefore represent an accurate picture of the sprint velocity.  Recognizing that burndown charts are also required at both the release and overall project level, reports can also be created to provide support for both of these.

Agile Sprint Story Burndown Example

And because these reports are using the full power of Microsoft project, a full suite of reports at the project level can be created to allow you to maintain full control over all aspects of your project.

Agile Project overview

The Project Dashboard provides a complete snapshot of the project, providing the same metrics from an Agile project that management would be accustomed to from a traditional project.  This consistency between Agile and Traditional projects is one of the key benefits of delivering Agile projects using Microsoft Project, as it preserves existing investment on Project and Portfolio Management and ensures that all projects are managed in a single comprehensive manner.

Reports can also be created to provide support for budget and resource management, again providing familiar project management tools for the Agile project.

Agile Report
Resource Overview

Iteration and Daily Scrum

A complete Work Breakdown Structure should be created to support and track all the work required to successfully complete not only the stories assigned to each iteration, but also all the Agile Rituals required within an Iteration.

Iteration and Daily Scrum

Product Backlog

The Agile Product Backlog, which contains all the Stories identified for completion in the project, has traditionally been associated with 3×5 Index cards containing a hand-written description of the Story pinned to a cork board.  The tradition continues with the Product Owner standing in front of the cork board, reviewing, adjusting and prioritizing the stories to ensure that the stories are valid and scheduled for the appropriate release and iteration.  However, in practice, very few (if any) projects remain true to this tradition and thus have automated the Project Backlog in a wide variety of forms.  Full support for the Product Backlog can be created using Custom Fields, Filters and Views to provide full support to the Product Owner for the all-important Product Backlog Grooming function.


The Product Backlog view uses custom fields to manage the status of the story as the Product Owner progresses the story through its life cycle following the defined process flow.

Product Backlog view

Once the story is set to “Sprint Ready”, the story is exposed to the overall project WBS and scheduled for completion in an Iteration, as discussed in the Iteration and Daily Scrum section above.

Iteration Planning

Each Iteration/Sprint requires “just enough” up-front planning to ensure that it achieves the benefits the Product Owner is expecting and that the scope of the iteration is within the capacity of the team to accomplish in the available time.  This ensures that all the appropriate tasks required to complete this Iteration plan are accomplished using time-boxed techniques (i.e. fixed duration tasks).

Iteration Planning

Release Planning

Similar to Iteration Planning, each release needs “just enough” planning to ensure that the release achieves the results expected by the business and that the end results are implementable to ensure usability by the business.  Following a similar approach for the support provided for Iteration Planning with a series of Fixed Duration tasks are used to ensure that the release plan is accomplished within the available time and that a high-level roadmap is created to define the strategies for the iterations within the release.

Release Planning

Project/Product Vision

In order to ensure that your Agile project achieves the desired business results, a Project/Product Vision is required.  A vision statement is similar to a traditional scope statement, but less detailed.  While a Scope statement is expected to clearly and unambiguously define the deliverables of the project, a vision statement is a much higher level document which outlines the business objectives to ensure that the project remains on target without constraining future flexibility to adapt and evolve.

Many projects will also involve a Sprint Zero to establish the project norms and technical environment.  Doing this “setup” Sprint Zero ensures that the effort required for startup is tracked and monitored separate from the project delivery sprints to ensure that an accurate and repeatable story velocity can be created.

Unlike most of the other Agile WBS elements discussed above, these planning tasks are defined as Fixed Work and managed by traditional management techniques to provide the flexibility to ensure that these tasks are completed before the initiating of the repeating time-boxed release/iteration cycles.

Project/Product Vision

Integration with Project Online/Project Server

As the Agile plan uses Microsoft Project functionality, it can be published to your organization’s PWA environment to take advantage of the enterprise and portfolio management functionality of Project Online/Server.

Most notable, all tasks associated with the Agile project are available on each team member’s timesheet, providing that all-important single point of entry to all time worked by a team member, whether on the Agile project, on other projects, and/or for support and administration activities.


Also, because the project is published to PWA, it is available for reporting at the organizational level, providing a single integrated location for enterprise portfolio and resource management.


About Sensei Project Solutions

Sensei Project Solutions is a Gold-certified Microsoft Partner specializing in Project and Portfolio Management (PPM) deployments with Microsoft Project and Project Server on the SharePoint platform.  With extensive experience on hundreds of PPM deployments and with thousands of users trained, Sensei Project Solutions brings a process-focused approach and support for industry standards and best practices to all engagements. We offer a complete set of services to help an organization make their Microsoft PPM deployment successful, including full implementation and support services, training, as well as pre-configured solutions, Apps, and report packs, including Agile reports and Agile templates.

Related Content

Webinars (watch for free now!):
Key Agile Concepts Illustrated
Using Agile Best Practices with Project PPM Technologies

What is Agile Project Management?
The Agile Project Manager: The Basic Roles in Agile Projects

Written by Steve Caseley
Steve Caseley, is a PMP, PMI-ACP, Scrum Master and is a Principal Consultant at Sensei Project Solutions. Steve has worked in the project management field for over 25 years, and has a wealth of practical experience in successful project delivery. As a result, he has many battle scars, but none have been fatal. Over the years, Steve has helped a wide range of companies implement PPM Systems and Best Practices and has practical, hands-on PM experience in a wide range of industries, project types and sizes. Steve’s passion is working with organizations to improve overall project delivery efficiency through the implementation and adaption of Industry Best Practices in Project and Portfolio management and implementation of effective PPM tools supporting these best practices. Steve has presented at international PM conferences and Microsoft Project User Groups over the years.
Share This Post
Have your say!
  1. Good Morning – is it possible to get a copy of the schedule that was used for this article? Thank you.

  2. Hi,

    To those of you interested in learning more, we have an agile overview and list of related resources here:

    If there is anything specific to agile that you would like us to cover, please let us know.


  3. Very good article. With Agile being so flexible, do you recommend using dependencies between tasks or use constraint dates?

  4. Hi Jim. I would typically create my stories as fixed duration tasks that run for the duration of the sprint as this gives the agile team the flexibility they need to work within a sprint. I would create Finish-start dependencies between the sprints.

Leave a Reply