11.8. Estimating Resources

Example of Estimating Resources in a Software Agile Management Project

In theory, resource management in Agile should be simple. After all, in Agile, resources and time are usually fixed. The team has a fixed budget, a fixed number of programmers (if software), and a fixed amount of time to create working software. The variable in all this is the software itself. Throughout the cycle of sprints—as the customer tries out new software, and requests alterations—the software features can change dramatically. When the budget is exhausted, the project ends. However, because Agile developers create working software bit-by-bit, the customer is assured of having at least some usable features by that point.

So again, resource management in Agile should be simple—in theory. But in reality, the key resource in software development is the people who create the software. In addition, where people are concerned, things rarely go as planned. Some programmers work faster than others, and individuals can vary tremendously in their output from one week to the next, especially when dealing with personal problems, like illness or family conflict. Robert Merrill (2017), a Senior Business Analyst at the University of Wisconsin-Madison, and an Agile coach, puts it like this:

Agile is more about people than computers. People are not interchangeable; they have good days and bad days. They get along or they don’t. Cognitive abilities vary tremendously. If you aren’t successful in helping teams’ gel and stay focused, you’re going to spend lots of extra money, or the project may blow up. You need to get the teams right (Merrill, 2017).

As Gareth Saunders (2015) explains in a thoughtful blog post on the topic, this is all complicated by the amount of “business as usual” tasks that developers typically have to fit into their schedules on top of their work on specific Agile projects. This includes tasks like “admin, team communications, support, mentoring, meetings, and consultancy—offering our input on projects managed by other teams” (Saunders, 2015). As a result, as a project manager, Saunders (2015) struggles to answer the following questions:

1. How do we know how much time each team member has to work on projects?
2. When we’re planning the next sprint, how do we track how much work has been assigned to a team member, so that they have neither too little nor too much work? (Saunders, 2015)

In theory, answering these questions should not be difficult. For instance, if you have, “five developers, each with 6 hours available for work each day”. That gives us 30 hours per day, and assuming 9 days of project work (with one full day set aside for retrospective and planning) then within each two-week sprint we should be able to dedicate 270 hours to development work” (Saunders, 2015). In reality, however, business as usual tasks can eat up 40% of a programmer’s working week, with that percentage varying from week to week or month to month.

Difficulties in estimating a team member’s capacity for work on a project is something every project manager faces. But in Agile, estimating capacity can be especially difficult. In Agile, project managers (or Scrum Masters) ideally exert minimal direct influence on day-to-day work, because teams are supposedly self-organizing—that is, free to manage their work as a group, and pull work when they are ready for it. This means Agile project managers need to take the long view on resource management by practicing good resource capacity management, which involves “planning your workforce and building a skill inventory in exact proportion to the demand you foresee. It lets you optimize productivity and as a concept perfectly complements the Agile methodology” (Gupta, 2017).