Data Driven Agile Methodology
Data Driven Agile
This article is for all software development team who follows agile methodology. It helps the reader to rate their agile process and to understand the importance of data-driven scrum process. At the time you reach the end of this article, you will know how a successful data-driven scrum methodology helps a scrum master/manager to predict the day-to-day growth of a project and indicates the profitability of the project by analyzing billable and non-billable ratio and bug costing.
What is Agile Scrum Process?
Agile methodology breaks the requirements into small incremental builds. Each builds are achieved by a Sprint that last for 3 to 4 weeks. Each sprint involves planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of each sprint, a working product is displayed to the customer and important stakeholders.
There is no strict rule that all projects should obey a common agile process. A good agile process should be flexible and the existing method can be tailored to suit any project requirements.
When can we claim a sprint as successful?
The success of a sprint depends on the following metrics:
1 Balance between ‘Planned Deliverable’ and ‘Actual Deliverable’ 2 Estimated Time and Actual Time (which have direct impact on project net profit) 3 Quality of deliverable.
Before going deep in to the article, one should have understanding on the following terms:
- Retained Project: (a) Long-term projects having dedicated resources to them. (b) A fixed 8 or 9 hours burnt every day by each resource as billable hours. Even in cases when there was no work assigned to the resource or any additional time worked by the resource on a day, the default 8 or 9 hours is calculated as billable hours for the resource.
- Fixed Bid Project: (a) Highly sensitive projects with strict end date and project estimation, expected to deliver on time as planned. (b) In case of delay or wrong estimation, no cost will be paid for additional effort and some time the client can claim compensation for delay in project delivery. Any number of resources can be deployed in this project to complete tasks in time.
- Time and Material Project (T&M): Irrespective to the size, this model fits to any projects whose requirements gets evolved as the time progress. In this project, resources are paid on the basis of hourly billing rate and the total time they spent on the project. There can be possibilities of negotiation between client and service provider on features enhancements, support and maintenance. This project suits best for support and maintenance.
- Billing Cost ($): The cost that a company or professional charges per hour of work. For example, the billing rate for a Data Architect may be $50 per hour.
- Salary Cost ($): Hourly salary paid to the resource, inclusive all benefits.
- Project Gross Income ($): Product of total billable hours contributed by each resources and their billing cost (Table 1A).
- Actual Project Cost ($): Product of total hours (both billable and non-billable) contributed by each resources and their salary cost (Table 1A).
- Estimated Project Cost ($): The project estimation is done by project manager with technical experts. Considering the amount of work and resources involved, the project estimation is prepared with respect to the billing cost of the resources involved and sent for client approval. Once the estimation is approved by the client, we kick-off the project.
- Bug Cost ($): (Total time spent on bug fixing and bug testing) x (Billing rate of resource per hour)
From Table 1A, if 20 hours spent by Sr. Consultant on bug fixing and 10 hours spent by test engineer on testing the bug, then
Bug Cost = (20 x 40) + (10 x 25) = 1,050 $
- Bug: Bug is a fault in functionality identified during unit testing or module testing before the code is released to customer.
- Defect: Defect is a fault in functionality reported by the end user or customer after the code is released to production.
- Known Issue: Any reported bugs moved to the production with mutual understanding between customer and engineers are called as ‘Known issues’ or ‘Open issues’. Generally they are low priority issues with less impact on system, but need to be resolved in upcoming sprints.
Let us have a look into the below table (Scheme 1), hope all scrum master can arrive at below table at the end of each sprint.
From the above chart, you can easily identify the successful sprints. Generally, any sprints with above 80% effort can be treated as successful sprints, again it differs from project to project.
Consider the data for Sprint 1 in Table 1 (Scheme 1):
Estimation of 500 hours was made to deliver 15 stories in this sprint. But the actual stories delivered was 10 with 3 open issues in 580 working hours. The pending stories and open issues are need to be planned in upcoming sprints, hence their estimations (F+G = 90 hours) are excluded from actual estimated hours to determine justified sprint time (H) and we arrived at 71% of Sprint Effort %.
Justified Sprint Time (H) = Estimated Time – (Estimated for Incomplete stories + Estimates for open Issues)
= 500 – (70 + 20)
Data Driven Agile (DDA)
In the earlier section, we studied how different factors like time, quality, and deliverable decides the sprint effectiveness. Now it’s time to correlate all this factors with sprints.
Mandatory for Data Driven Agile
Timesheet application: Does your timesheet has flexibility to capture time against your working project with different development tasks like Coding, Testing, Designing, Planning, Implementation, Bug Fixing, etc. If yes, then your timesheet fits for DDA.
Project Management Application: Application with flexibility to assign hours to Sprint stories and captures Sprint Start Date and End Date effectively with projected sprint estimation hours.
Bug Tracking Tool: A tool to capture issues against different stories in a sprint.
If we have all three tools in place, then we are ready to implement DDA in our project.
When we correlate or integrate data from all three tools, you can easily arrive at the performance of each sprint, as well as your team member contribution percentage in the sprint. It is not necessary you need to wait for a sprint to complete and take initiative action, you can monitor every day growth of your sprint by having all these data integrated in one place and scheduled to get updated every day. This can be achieved by using any simple data integration tools.
In Scheme 2, you can see two new factors, Non-Billable Hours and Non-Billable % are added. These two factors add value to effective sprint and decides the profit percentage of your projects.
Non-Billable Hours (J = B – H): Any time spent outside the estimated project hours are called as Non-Billable hours. In reality, we cannot expect any projects without Non-Billable hours, but it is always good to reduce the volume of your non-billable hours.
Non-Billable Hours % (K = J/B * 100): Percentage of non-billable hours to actual time spent.
Effects of Data Driven Agile
Below are some key metrics, which can be easily determined using data driven agile methodology.
Sprint Burn up Chart:
Project Burn up Chart:
Bug Triage report by Sprint and resource: Categorize bug by Severity, priority, sprint, and owner.
By tracking bug count and time spent on resolving the bug we can also calculate the bug cost in a project or sprint.
Bug Life report by Sprint and resource: Age of open bugs, helps to fix them by priority.
Effective Contributors in Sprint and Project: Resource with high Sprint Effort % and less bugs owned.
Least Contributors in Sprint and Project: Resource with low Sprint Effort % and more bugs owned.
Billable and Non Billable Ratio: Billable hours vs non-Billable hours.
We can easily calculate how much of non-billable hours are burnt in a project, and how that impacts overall project velocity.
Project Profit: Estimated vs Actual time (can be converted to estimated cost vs actual cost)
=> Project Gross Income – Actual Project Cost
For example assume your Project Gross Income = 10000$, actual project cost = 7500, then
=> 10000 – 7500 = 2500$
To determine the true velocity of the project, we need to consider Bug Cost
=> Project Velocity Rate = (Project Profit – (Actual Project Cost + Bug Cost))/ Project Profit x100
Assume bug cost of your project is 500$, then
=> Project Velocity Rate = (10000 – (7500 + 500)) / 10000 = 20 %
The more the velocity rate, the more the project success.
As like project velocity rate, we can also determine the velocity rate for individual sprint and resources.
The goal of data driven agile is to track the project/sprint growth day to day and take immediate action to improve the project and make quality deliverable on time. In addition it also help us to arrive at different project management reports and provide clear vision during sprint estimation and resource allocation.