Agile Project Selection from a Portfolio of Projects


When an Agile methodology is introduced to an organization for the very first time, it’s quite common for the client to ask: What are the characteristics that indicate a project will have the highest likelihood of success? Most experienced Agile practitioners have an intuitive feeling for which projects would be successful using an agile methodology. This includes such factors as the project having a direct contribution to business value, or having a dedicated business customer. Even though this may be understood by the experienced practitioner, that does directly help the program manager with the selection process.

This article describes an “Agile Scorecard” that can be used as a first pass filter for selecting Agile projects. The intention of the Agile Scorecard is to provide a simple manner in which projects can be reasonably selected by a project team that is unfamiliar with agile methods.

I had misgivings when writing this article because it describes an approach that is based around following a procedure and a checklist. This is distinctly not Agile. But refusing to discuss this topic doesn’t help anyone, and so I’ve decided to start this article with the following caveats:

  1. The Agile Scorecard is not a substitute for an experience Agile coach. A good Agile coach can offer more accurately and specific advice that I can encode in a scorecard. If you’re thinking of adopting an Agile methodology, then you need a good coach.
  2. The Agile Scorecard is only valid for the first 18 months. After 12 to 18 months of selecting projects, your personal experience will be more relevant to your organization than the scorecard can ever hope to be. The scorecard should be viewed as an interim solution to help guide decision making until the project team has sufficient experience to use their own judgment.

The Scorecard is simply a list of criteria that can be matched against the characteristics of a particular project. There is also a score associated with each question. The intention is to simply tally up to scores and based on the total number, determine if the project is suitable for “the Agile treatment”.

To give the scorecard some structure I’ve divided the criteria into three broad categories; Business, Project and Technology. Each criteria is discussed is more detail below:


  • Is senior management actively interested in the outcome of the project? Senior Management interest is always a good thing. Although interesting is not a prerequisite for a successful project, it can help the adoption of Agile methodologies throughout the organization. More interest from Senior Management is better.
  • Does the software have direct business value? Being able to demonstrate a successful project that immediately adds value to the business can have a very large impact on how successful the project is viewed by management. Obviously if the product brings in revenue on day 1 of being release, it will have a great deal of visibility. This is good for both the project team, and for adopting the agile process throughout an organization. A project that directly contributes to the bottom line is better.
  • Is this a Greenfield project (i.e. new development) or is this a migration of functionality? I’ve personally found that Agile projects have more visibility (and therefore more recognition of success) when used for new software development rather than the migration of existing software. Agile techniques can certainly be used for migration projects, but when starting to introduce agile into an organization, it’s important to take successful projects early on and to tackle migration efforts once Agile has been introduced.Migration projects can be very tricky from a business perspective, because there’s always an argument that any money spent on a migration effort, can be better spent on understanding what the current business requirements are. This is a very valid argument which cannot be dismissed easily.New software development projects are preferable to migration efforts.


  • Is there a single business customer who is fully dedicated to the project? This is arguably the single biggest factor in the success of an Agile project. Having a business customer (also know as the Product Manager, Product Owner, Client etc) dedicated and available to the project greatly increases the flow of communication between the entire team and hence reducing risk and uncertainly within the project.A single customer is the ideal situation [1]. It allows for immediate response and clear decision making. Having 2 or more business owners introduces the possibility of conflicting opinions, resolving different agendas and politics of product development.A single, dedicated customer is ideal. Everything else (such as multiple customers, off-site customers, customers split over several different projects) is sub-optimal.
  • Does the project have an experienced Coach/Mentor? This is important particularly for new teams that are adopting agile. An experienced coach can share experiences, suggest approaches that have worked in the past and, most importantly, share approaches that have not worked.Without the guidance of an experienced coach, a new team will learn from their own mistakes. There is definitely some benefit of learning from one’s own mistakes, and some organizations actively encourage this. However, this has not been true of the large corporate environments that I’ve worked with in the past where an individuals position is only as good as their last project. In such environments having an experienced coach is essential.
  • Is the development team co-located? By “co-location” I mean that the project team is located in the same building, on the same floor and in the same project room. Agile software is very dependant upon high bandwidth communications. A lot of effort is made to ensure that the right parties are communicating frequently and clearly. Any disruption to this communication stream increases the risk of the project, so it follows that distributed projects have a higher level of risk than a project that is done entirely onsite. Communications, documentation, and code quality can all become problems that need addressing.Given that the economic benefits of distributed Agile are still unproven, it makes very little sense for a new project team to even consider distributed Agile.[Sidebar: Distributed agile is possible, but it definitely requires more experienced than the average team can bring to the table (at least initially). Even then, it hasn’t been shown that distributed agile can be one successfully on a consistent basis.Here are two links to articles that discuss distributed agile in a very positive light [2], [3]. In both cases the vendors are actively involved in selling distributed Agile services. In addition, the second article was commissioned by the vendor.]
  • Are the requirements of the project well known? Are they documented? Agile methodologies were created with uncertainty and change in mind. Undocumented, unclear or poorly defined requirements present little difficulty and would align nicely with an agile methodology. In contrast, requirements that have been documented in detail would be clumbersome in an Agile environment. This doesn’t mean to say that Agile project do not have specifications; just that the specifications may be less formal or at a higher level.
  • Is the team cross-functional? Having a team that encompasses all the necessary disciplines (Analysis, Coding, Testing etc) is necessary to create a team that has all ability to determine how best to solve day-to-day problems. In addition to providing a shorter feedback loop, this servers to increase the visibility of any problems faced by the team allowing them to be address and resolved in a more effective manner. Inefficiencies are introduced as soon as the project team has to rely on an external party.


  • Is the project team using some form of continuous integration (anthill, CruiseControl etc)? Continuous Integration is the constant building, integration and testing of software that’s currently being developed. Better people than I have described CI in length [4], so I won’t go into details about it. The more frequent the build process the better.
  • Is the team doing Test Driven Development and/or Pair Programming? Test Driven Development and Pair programming are two of the hardest Agile practices to put into place. Even for experienced teams, it takes discipline. For many teams pairing for 8 hours a day is simply too difficult and aim they for 4 to 6 hours a day. It may take as long as 6 months or longer for a team to start doing TDD consistently. Both of these practices are hard to implement because they require a change to the developers behaviour and the way in which they write software. Making the change an lead to substantial benefits, but it takes time and effort before either of these practices become second nature.The more Pairing and TDD are practiced, the better.
  • Does the team have ready access to necessary tools (JUnit, NUnit, Fit/Fitnesse, Clover, etc)? It may be obvious to state that the project team should have access to the tools necessary to do their job. I’ve found, however, that it’s very common for a project team to be told what tools they must use, rather then letting the team decide. In order for teams to be self determining they need to be able to choose the tools and environment in which they work. For a good list of tools see [5].

How to use the Agile scorecard
I’ve tried to make the scorecard (and by implication, the scoring) as simple as possible. Start with a score of zero and answer each of the questions in turn. Depending upon the answer the score is either increased or decreased. The amount by which the score is increased (or decreased) is noted in the comments. Not all of the criteria are equally important and I’ve weighted those that I feel have more importance. This weighting is based on personal experience, so I’m open to suggestions on how it can be improved.

After the scores have been tallied and a total project score is obtained, a final recommendation can be made as follows:

  • If the project score is less than 5. The project is a poor candidate for adopting an Agile methodology and should be address using current development processes.
  • If the project score is greater than 5. The project has characteristics that would make it suitable as a pilot Agile project.

Concluding remarks
The Agile Scorecard as presented here is a way for project teams that have little or no Agile experience to determine if a project would likely be successful using an Agile Methodology. The Scorecard is a simple (and crude) technique of filtering projects from a portfolio of projects, and is not intended as a replacemet for experienced advice. It may, however, provide sufficient advice to get a project started with Agile.



I’ve been having difficulties viewing my past blogs. Even trying to navigate with the calendar resulted in an exception. If I’ve been having difficulties, I’m sure others have been as well. As an interim solution I’ve decided to archive my material at

Download the PDF version: Agile scorecard blog

Posted in Agile, ScrumWorks

Leave a Reply

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