• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Ratio of Developers to Analysts in Agile

Conventional wisdom generally holds that the ratio of developers to analysts in an Agile framework is about 4:1 or 3:1. In essence, it says that 1 analyst can support the work of 3 or 4 full time developers working on a project. For Waterfall projects, this ratio is higher and typically in the range of about 8:1. In practice, I have found that the ratio of developers to analysis in Agile development is accurate, but it tends to fall apart once we take testing into consideration.

In a traditional Waterfall model, the requirements are done up front and handed off to the development team. While development is underway, there is a hiatus of sorts for the analyst and this time has typically been used to bring the testing teams up to speed. Detailed review sessions are conducted with the team, data needs defined, test data is created, automated scripts developed and the team is ready to begin testing by the time development is done. However, this luxury of time and preparation that Waterfall provides is not available in Agile.

When working on 2 or 3 week sprint cycles that are pretty common in many Agile shops, I find there is a tremendous strain on both the test teams and the analysts supporting them. Simply put I find there is not sufficient time for the analyst to work with the test team to support them adequately. While the sprint is underway, the analyst is doing two things that are critical to development. First, they are actively supporting the development that is ongoing by working closely with the developers to answer their questions and flesh out details as they go through the process. Second, they are working on requirements for the upcoming sprints so that they can keep the backlog healthy and ready to keep the wheels turning. What little time is left apart from these two activities is devoted to testing.

In practice, I find the whole process disjointed with the test teams getting short shrift. They end up getting the bare minimum in support and input from the analyst. This problem is particularly acute in teams that are transitioning to Agile from Waterfall. The test teams are used to a certain level of support and input from the analyst that is suddenly drastically reduced. Yet the demands on the test teams or the expectations of the level of coverage and testing is not reduced. In essence, they are being asked to do the same levels of testing with significantly less analyst support. This has resulted in more problems later in the release cycle as we get closer to launch and ironically, a lot more fire drills than I have experienced in Waterfall projects.

Agile is very developer friendly but puts tremendous strain on the analyst and testers. This problem becomes a lot more acute when dealing with complex applications with multiple dependencies and a legacy code base. While unit testing a specific piece of functionality is relatively straight forward, understanding all the upstream and downstream implications becomes extremely challenging in time constrained environments. This problem is further exacerbated when the analyst is giving the minimal support she is able to the test teams.

So how do we get around this problem? There are a couple of possible approaches that can be experimented with. First is to consciously increase the lengths of the sprints to accommodate testing needs. An increase of about 33% will go a long way towards freeing up time for the analyst to adequately support testing while also tending to the needs of 3 or 4 developers on a team. For example, if the initial plan called for 2 week sprint cycles, move it to 3 week cycles without increasing the scope of each cycle. This will mean a lower velocity overall from a development perspective, but will give adequate time to do better testing. In the long run, I believe that this will lead to a better final product.

A second possible approach will be to have analysts who are dedicated to supporting test teams. These analysts can work across multiple sprint teams but their sole focus is in supporting the test teams. From practical experience, I think that one analyst can support the work of 2 or 3 sprint teams. Since they are solely focused on looking at the overall solution from a testing perspective, they are in a better position to look more carefully at interlocks, dependencies and impacts across the board. They can also give the time and dedication that the test teams need to create data, understand the scope of testing and development of automated scripts.

In short, what I am advocating is that we treat testers in the same way that we treat developers in an Agile framework. We need to size the amount of effort needed by analysts to support testers and staff accordingly. By focusing solely on the ratio of developers to analysts when coming up with staffing models, I believe we are missing a significant chunk of effort and introducing risk into our projects without intending to do so.

2 Responses to Ratio of Developers to Analysts in Agile

  1. R February 22, 2019 at 8:35 am #

    Good info Ajay

    Do you have other ratios that could be useful.

    Project : % of architects, analysts, developpers, ops, security, …; example : project of 10,000 days, % of days for the Project leader, architect, analysts, developpers, testers (IT and Business)

    Continuity : maintenance of application : same question

    In Waterfall and Agile modes

    Thanks a lot

  2. Ajay Badri June 29, 2019 at 2:08 pm #

    Thanks a lot for your question on additional ratios.

    In general, staffing of a complete project is typically based on the historical information that the company has developed over time in terms of resource utilization. One common method is to use development estimates as the starting point and build the rest of the team around these estimates.

    For example, an effort estimate of 10,000 hours of development that is targeted for delivery in one year, will need 5 developers (assuming 2000 hours per developer year). For an Agile project, you would end up with 1 full time project manager, approximately 2 full time analysts (1 analyst per 3 full time developers), 2 business testers and 2 IT testers. A simple rule of thumb is to match the number of analysts and testers as a starting point for planning and fine tune from there.

    The number of architects needed will depend on the number of different areas of the infrastructure and application stack that need modification for a solution. I would hesitate to simply use a number here as architect skills are not easily transferable from one domain area to another. The number of architects should be dictated by the solution and real world knowledge instead of simply sticking a number in a planning bucket.

    I will use the same rules of thumb outlined above for planning for the different project types you mention.

    For Waterfall, I will increase the number of analysts and testers by 1 to 2 in the example here. My rationale for this is the work is front loaded for analysts and back loaded for testers in Waterfall, when compared to Agile where the work is smoothed out over time. The amount of work is (likely) the same but the time to deliver the requirements or test results is much shorter.

    For any of the resource numbers here, please treat these as ‘Full Time Equivalents’ as opposed to dedicated resources. The actual staffing will dictate whether the work is given to dedicated resources or split among multiple people working a portion of the time on the project.

Leave a Reply

Your email address will not be published. Required fields are marked *