Project Reporting in Agile Projects. Introduction. At software architects we live and breathe agile development. We started with Scrum in the early days of our company when we built the first bits of our flagship product time cockpit. Over time we changed to Kanban but the agile principles have been our constant companion for many years now. Besides developing time cockpit, we also license our base technology called Cockpit Framework (short Co. FX) to other ISVs and help them building cloud- based Saa. S solutions. Of course we work agile in such projects, too.
Agile Program Management Best. Innotas Agile Portfolio Management solutions provide a much. Detailed Resource Planning and Management; Consistent Reporting and. Retooling Your Approach for Agile Success Executive Summary PROGRAM MANAGEMENT FOR AGILE Sponsored by: PERFORMANCEINSTITUTE.ORG Robbins-Gioia, LLC.
Agile Project Reporting and Metrics. author of Agile Project Management. The term refers to value as expressed by the project or program budget.).
But one thing differs: Project reporting. Although most our customers understand the ideas of agile development, the simple facts of real- world business life force them to think in budgets, milestones, project plans, etc.
Agile Program Management. Agile program management software enables complex reporting that meets the needs of larger enterprises. Manage program-level features using. 2 Agile Program Management — Success through effective teaming Predictability, visibility and flexibility to achieve results Organizations are constantly seeking. Seven transformational patterns for Lean-Agile Program Portfolio Management. where they can share best practices and common program measures and reporting. Get unparalleled management visibility with agile reporting of agile project management metrics with 50+ pre-packaged agile reports. Program Management for Agile: Transitioning Toward a New Organizational Paradigm 2 For more than a decade, Agile methods such as Scrum, XP, and Kanban have proven very.
Project Reporting in Agile Projects Friday, August. Agile project management does not eliminate the need for upfront. Program Management Systems Committee. Project, Program, and Portfolio Management Theme: Process at Scale. Chair: Troy Magennis. Co-chair: Linda Cook. Description: This track is dedicated to sharing.
Over the years we have developed a solid practice for reporting in agile projects. It tries to bridge the (apparent) gap between classic project management with rigid, upfront project plans and ever changing environments in agile projects. In this article we would like to share our most important learnings. Additionally, we describe the KPIs on which our reporting practice relies.
The Core Question: Are We on Track? Are we on track?” This is the core questions our customers want to have answered by our regular - typically monthly - project reporting. We break down this question into two aspects.
How are we doing in terms of budget? Will we be able to finish on time? These questions are not specific to agile software projects.
They have been playing an important role as long as project- oriented work exists. Therefore, we did not have to invent a completely new reporting and KPI framework. We could build on something that’s already there: Earned Value Management (EVM) (see also Earned Value Analysis for further information in German). Standardization and Practical Use of EVM EVM is defined in the ANSI/EIA- 7. The standard plays an important role especially for suppliers for the US government and the US Department of Defense (Do. D). The National Defense Industrial Association (NDIA) has published an additional guide  how the US government has to apply EVM in its project.
An EVM implementation guide is also available from the US Do. D . These documents are probably interesting to read if you want a deeper understanding of EVM and its practical implementation. A related standard for German- speaking Europe is DIN 6. It defines the term Fertigstellungswert which is essentially the same as EVM’s Earned Value. Earned Value Management (EVM).
The basic idea of EVM is that you have to “earn” your project’s budget by completing scheduled work. At the start of the project the Earned Value EV is 0 because you have not completed anything. At the end of the project you have earned the entire Budget at Completion (BAC) assuming that you have completed all planned work.
The following chart illustrates the relationship of Earned Value, Planned Value and Actual Cost. At milestone t. 1 - could be e. EV > PV, Schedule Variance SV > 0). Therefore the team is performing better than planned in terms of schedule. At milestone t. 2 the situation is different. More work should have been completed at t.
EV < PV, SV < 0). Additionally the team spent more money than it should have until t. AC > EV, CV < 0).
Let me describe the basics of EVM with a very simple example. Think back when you were a little kid and your parents promised you 1. From experience you knew that this job would take you 2 hours. So your hourly rate would be 5$. EVM would call the 1. Budget at Completion (BAC).
You plan to get something to drink after having mowed half of the lawn. EVM would call this a Milestone.
The Planned Value (PV) for reaching your milestone would be PV = 1. Your Schedule according to EVM would be to reach your milestone after 1 hour and finish your work after 2 hours. Equipped with this knowledge you get the mower and start your work.
After 1. 5 hours you finished 5. In this extremely simplified example, EVM could help you to answer the question mentioned above: Am I on track? According to EVM you would calculate the Earned Value (EV) when you have reached your milestone. EV = 5. 0% (completed work) * 1. Budget) = 5$. Now you can compare EV with your Actual Cost (AC) to get the Cost Variance (CV).
AC = 1. 5 hours (time need to reach milestone) * 5$ (hourly rate) = 7. CV = EV - AC = 5$ - 7. A negative value for CV indicates that you are not on track in terms of budget! Your goal would be to have a CV > = 0. You can also get an indication whether you are likely to finish in time. For this you could calculate the Schedule Variance (SV) after working for 1 hour. SV = 0$ (EV after 1 hour because you have not reached any milestone)- 5$ (Planned Value PV after 1 hour) = - 5$.
Again the negative value is an indication that you are not on track in terms of schedule. As a manager you would need to dig deeper, find the root cause of the problem, and take the appropriate actions. Big Upfront Planning for EVM in Agile Projects? At a first glance EVM looks horribly old- style for someone who values the principles of agile development.
In order to be able to calculate EVM’s KPIs, you need an overall budget, a milestone plan, work items with cost estimations, network schedules, etc. All this assumes some upfront planning. But isn’t agile all about avoiding big upfront plans and designs? Agile does not mean that upfront planning is unwanted or even impossible. In his book The Scrum Field Guide the Author Mitch Lacey describes how release planning works in Scrum. The starting point is the product backlog. Whenever we start a project with a customer, we start with scoping workshops in which we work out high- level requirements (aka Epic Stories).
They make up the initial product backlog. A book that we highly recommend in this project phase is Stephen Withall’s Software Requirement Patterns (Best Practices). Next, we set the scope for the initial release together with the customer. The product backlog for the initial release gives us all we need to start with EVM.
It does not even matter if you choose relative (e. T- Shirt sizes) or absolute numbers (e. Dollars) to estimate the effort for the items in the product backlog. You can always calculate the EV and compare it to the PV. Use Ranges Instead of Single- Value Estimates.
Regular readers of our blog know that we believe in range estimations when it comes to effort estimation. This influences the way we handle the PV, as the following figure illustrates. Our customers always get estimations in form of lower and upper bounds. In many cases the upper bound acts as the cap of the project’s cost. Practical Example. So how does this look like in practice? Let’s assume a rather simple project.
The Product Backlog consists of five work items (=Epic Stories). For every backlog item we have an estimation in person days (lower and upper bound). The employees record their working time per work item. Assumptions (simplifications). Linear resource investment (if the plan would assume less resources at the beginning and more resources at the end, the model would be more complex). Only direct costs, indirect costs are not taken into account. Only personnel costs, no material costs.
The following table shows how a simple project report could look like. It starts with the effort estimation, the actual costs, and an estimation of the completion per work item. Based on these KPIs, EV, PV, CV, and SV are calculated.
As you can see in the table, the project is on track in terms of schedule (SV > 0). In terms of budget the project is not perfectly ok as CV is < 0 compared to the lower bound but still > 0 in comparison to the upper bound.
For us this would be a clear indication that costs and budget has to be closely monitored and managed in this project. Effort Tracking in Time Cockpit. Analyzing effort each month is important but in our experience not sufficient. Therefore we monitor the effort continuously using dedicated time cockpit lists. They show the estimated effort per work item (lower bound because this is what we always try to achieve) and compare it to the actual effort. The following figure shows such a time cockpit list.
It is taken from a rather small project directly out of our productive system (click to enlarge). Where is Agility? As mentioned above, EVM can definitively be applied to agile projects. However, there is a certain risk of losing agility. It is important that all stakeholders understand that the plan which underlies the EVM calculation is not fixed.
It has to be adopted to the learnings during the project. If the product backlog changes, the EVM calculation has to be changed accordingly. In our experience the secret of success it to make sure that people responsible for budgets understand the agile approach. They have to learn that agile projects do not have an upfront plan that is frozen and must not change. We have seen that EVM- based reporting helps e. Scrum project to recognize budget issues in an early stage of the project. Today many peoples apply EVM to agile projects and write about their experiences.
If you want to dig deeper into this topic I encourage you to read the articles Earned Value for Agile Development and Agile. EVM – Earned Value Management in Scrum Projects.
Lessons Learned. Over the years we had to learn some lessons regarding project reporting the hard way. Here are our top learnings which we want to share with you. Establishing a good project reporting practice is important and many teams struggle with it. EVM is a good extension to e. Scrum as it helps to identify budget issues in early project stages.
Agile project management does not eliminate the need for upfront planning. However, you should carefully manage the effort for upfront planning and delay any planning work that is not absolutely necessary for the initial budgeting and scoping phase. Make sure that all stakeholders (including budget owners) understand the idea of agile development.