Currently IT industry is barraged with articles on Agile i.e., #BeLean. AGILE’s basic premise is to be lean yet measure and track matrices. #GOAGILE, #BEAGILE, #AGILITYLEADS and many more hashtags around #ONLYAGILE does not mean cut corners. Lean Engineering gurus have been teaching to go #AGILE and be #LEAN. Being Agile is to be nimble, to be able to adapt to the changing needs of company to achieve goals as to what is desired by business. We need Agility to achieve measurable parameters i.e., not just measure outcome but also Project management specific measure. What if I say we should not just track Velocity, Burn down and Burn up charts but also EVM.
Agile Project Managers so called “Scrum Masters” most often keep calling “Scope is Dynamic Hence Agile”, “Do not know what will be the scope for couple of sprint down the lane and hence it is not possible to forecast outcome after 2 sprints”, “Do not know what will it take to deliver the complete full scope”.
It is important for stakeholders to know few key parameters for any project be it a IT industry or civil or mechanical etc. Key parameters to know Quality, Schedule and Cost. There are measures like Velocity and Burn down\Up charts available to track project health, most of the key agile metrics revolved around outcome i.e., how much value has been realized thus far and will be realized over time. These are important and very helpful for business sponsors to take decision based on ROI however when it comes to metrics for Project manager and IT liaison to help them decide next steps to meet business objects are limited.
These limitations can easily be handled by leveraging EVM which got evolved over time to report, forecast, monitor and keep a track of project progress for traditional projects. Agile EVM complements Velocity and Burn down/up charts for Agile projects to keep a track of project health and forecast project status.
For shorter sprint cycle EVM might not be that helpful however it helps track project status better than mere Velocity and Burn down charts since project risks and uncertainties are measured on daily basis for smaller projects. Agile EVM will be very helpful and handy for long term projects especially with more than 2 months duration. EVM can be leveraged to handle dynamism in sprint scope, be it addition of new user stories to the scope or spillover of few incomplete or partially complete user stories to next sprints. Practicing Agile EVM can help govern Agile project’s accurate status, spotting initial signs of worry, as well help forecast end-state based on up-to-date project data.
Does Agile scrum master need to track extra parameters to come up with EVM, answer to that is “No”. It is up to scrum master how to extract EVM details from the Agile specific trackers. Let me share how I use to derive Schedule variance and Schedule performance Index from the simple Agile tracker.
Objective is to come up with the dashboard as show below, which has Agile and Traditional project management matrices.
Here is a sample snapshot of task tracker sheet with 8 fields\parameters
Parameter # 1 >
Task #: This is the unique task number for project.
Parameter # 2 >
User Story #: This defines the unique number for each user story shared by BA which captures the functional requirement and acceptance criteria.
Parameter # 3 >
Task Description: This defines the exact task which got derived based on WBS modeling. Generally, task should be within the range of 3 to 8 hours for optimal tracking however there could be exceptions.
Parameter # 4 >
Complexity: Individual developer or tester (task owner) defines task complexity, which will be leveraged for fine tuning estimation techniques be it a Pocker or POM model estimation.
Parameter # 5 >
Story points: # of story points allocated to each task in the beginning of the sprint by team using one of the accepted Agile estimation technique.
Parameter # 6 >
Start Iteration #: Purpose of this is to track in which iteration this task is planned to be accomplished.
Parameter # 7 >
End Iteration #: Purpose of this is to track in which iteration this task got finished and realized or earned value.
Parameter # 8 >
Total Hours #: Actual effort spent against each task, which has a break up of productive and nonproductive hours for each row.
Let me take first section and explain how to derive this view.
Create a Pivot with “Start iteration #” as Column parameter and “End iteration # “as Row parameter. Values are derived from the “# of tasks”. Similar views can be plotted using other unit of measures like “Hours” and “Story points”.
- Values in green boxes reflect, # of task completed as per plan, however it does not help us understand if they were closed within the defined time or schedule.
- Value in Amber boxes define, # of tasks slip to the next sprint.
- Value in Red boxes or cell defines, # of tasks slipped by more than 2 sprints, which is really a concern and need immediate action.
- Column with PV as head, defines # of tasks planned to be completed in each sprint. This takes care of spill over task count for next sprint, hence total number of tasks cumulatively in the sprints will not be the right measure.
- Row with Value, depicts number of tasks completed in each sprint. This is known as Velocity in Agile terms.
- SPI row depicts, Schedule performance Index (with # of task as base unit).
- SV row depicts, Schedule variance (with # of task as base unit).
- AV row depicts, Actual cumulative Value sprint on sprint (with # of task as base unit).
- Average Velocity will be simple average of Values with row headers as “Value”
- Assuming a scrum team of 2 developers, average # of task accomplished by team can be derived. Given sample less than 2 task are completed by developers per sprint.
- SPI and SV help measure if project is off track or on track in terms of meeting the release plan, which can be leverage by scrum master to adjust capacity and take appropriate decision. RAG status for the SPI and SV values help define Project Schedule Health.
Based on effort tracker team’s productivity can be derived for other decisions.
Based on PV and AV, Burn-up chart can be plotted which can help track how much business value has been achieved thus far.
On similar lines based on capacity and cost per hours for resources CPI and CV can also be derived.
It is not mandatory to track EVM for Agile projects but I believe Earn Value measure help track project progress and provide different view on the project health. Earn Value perfectly complements Agile metrics. Hope this helps understand how simplified AGILE EVM can be draw for scrum based projects.