Agile Based Planning Using Active Time
One of the new ideas coming from the Agile Methodologies are two different ways to look at planning software projects. These are the notions of ideal day planning and capturing the team's velocity for planning future iterative releases.
Ideal Days
In ideal day planning, you examine the capabilities of the team to deliver work within an "ideal" day—usually defined as an uninterrupted, 8 hour span of time. Then all of your estimates are made using ideal days. This focuses the team towards full days of focused activity when thinking of and estimating the project work that needs to be done. Some of the agile methods subscribe to pair-programming, so these ideal day estimates would represent the effort associated with two developers.
Of course, ideal days then need to be translated into the real world that includes interruptions and work not associated with the project(s) at hand. That mapping usually falls to either the coach or project manager to make as part of the planning process applied to translate the team's efforts—forward—into predictable functional delivery dates.
What's nice about ideal days is that it's simple and it abstracts the team from worrying about and trying to factor in for interruption and even padding for different member skill, capabilities or overall uncertainty.
Velocity-Based
Another option is to measure your individual, or far more important, team's velocity—then use this as a gauge in predicting future schedule performance. One unit for velocity can be ideal days of effort. That is, for each schedule deliverable (or iteration) how many ideal days of effort were actually expended towards the project? From a planning predictions perspective, you would then use this to predict future capabilities and adjust the schedule as required.
Another unit of measure within agile teams is story points. Story points are units that try and capture the size and complexity of XP-like feature stories (think of them as small use cases for lack of a better definition). You would then measure velocity in the number of stories the team can implement within each development cycle or iteration. Usually one story point is equivalent to an individual (or programming pair) working on a story for a single day (ideal day). However, in this case, it's not just a measure of time, it's also a measure of size.
Using Active Time
Bringing the discussion back to 6th Sense Analytics a bit, we measure Active Time as it relates to project teams focused towards delivering low level artifacts (code, tests, etc.) for the project. Since it's so finely grained, activity focused and highly accurate, Active Time becomes a good candidate for velocity-based planning units.
In order to "close the loop", you would need to have the team start making their task estimates in Active Time as well. But again, the data is available for team members to analyze their work activity and performance patterns and make Active Time estimates based on their historical data. Also, if you use a PROBE type technique, you can bring the Active Time historical data down to very specific types of work.
Of the two methods, I'm convinced that velocity-based planning is becoming a leading approach for planning software projects—clearly in the agile camp, but also within more traditional teams at the development level. Traditional project managers seem to be a bit stuck in their methods and slow to adopt it.
Fundamentally the approach disrupts the traditional planning model of:
Estimate –> Plan –> Track –> Make it Happen
To one that more realistically reflects the dynamics of software projects:
Estimate –> Plan –> Monitor Velocity –> Adjust to Reality
Instead of trying to draw up a plan and hammer the team into submission, velocity planning guides you towards a goal based on the true capabilities of the team as they face the challenges and discoveries along the path. The realities across the two methods are the same, it's just a decision of whether to pay me now or pay me later?
If you're interested in more information on the topic, Mike Cohn has written a great book Agile Estimation and Planning that nicely covers the topic. I may also explore it further in future posts.
Previous Post:
Innovation happens with 6th Sense
