Combining Agile PM with Traditional PM in one PPM tool…

(by Peter Stevens, PMP)

In the following blog I’ll try to answer the question how to integrate an agile project schedule into a higher level traditional project schedule, using PPM tools.

To answer that question, we must first address how one would schedule an agile project using traditional tools. One of the principles of agile projects is the sprint, which has a fixed duration of a few weeks, where few is less than four. I prefer two. And the team decides with the product owner, who ultimately sets the priorities, what goes into the current sprint.

The planning horizon of the team is one sprint. This approach resembles a rolling-wave schedule: we detail within the Planning Horizon, and the rest is at top level. Does that mean that for the current sprint we should have a detailed schedule? I’m not sure. In fact, I do not think it’s needed: the team decides what goes into the sprint, and commits to do their best to have all of that done at the end of the sprint. Note that developers often use tools like Jira, which have no scheduling capabilities (and therefore not suitable as a tool for mixing traditional and agile project management), and they are perfectly happy with that. When the developers elaborate on the work to do for a release, they actually do spend time on planning, they determine the sequence of things, risks, relative complexity, etc, at a high level. So, here you have something that resembles a ‘traditional’ planning. And you can set budgets, based on expert judgment.

However, these budgets are at high level, “epics”, or even higher, and the accuracy is limited. Moreover, the epics will not be detailed yet until the functionality to be created by the particular user stories in the epics is on the Agile Planning Horizon. Nevertheless, we can track progress on these epics. The way this is done is as follows:

  • The epics have budgets
  • At the end of each sprint the scrum master works with the team to determine how much of each of the epics has been done. “Boys and girls, with what we know today, how much of epic 1 is still left?”, and then with the actual hours written, you have a good guess of where you are and since you know exactly how big the team is working on the sprint (i.e. how much time=”money” they spent), you know the actual cost.

If you see that you are exceeding budget, then the product owner will have to work with the team, and customer to look for clever solutions. Note that it is advisable to do at least assess each epic asap, to understand (the impact of) the guess of the complexity of each epic.

Although cost spent is fairly accurate (especially when time writing is facilitated), the required funds for the complete set of epics is always fairly high level and not accurate. This is the ‘nature of the beast’: agile is based on progressive elaboration and cost in the future are always difficult to predict. However keeping track of spending versus actual budget gives the team some food for thinking. Which is very valuable. Note that the team may not work continuously on an epic; there may be dependencies which require them to work on a part of A, then a bit on B, then complete C, and back to A etc. Trying to detail this early is useless, as things change too much. So any planning tool to uses should be able to deal with this (time phased actual work) at the epic level.

 

Ing. Peter Stevens, PMP studied Business Administration Electronics. He started in software development and became manager of the Telecom Operation Support Systems at Alcatel-Lucent. In that role various management and leadership skills were developed which made Peter a successful project and team manager.  Peter is passionate about scrum and software development.

Leave a Comment

Start typing and press Enter to search

X
X