the importance of this concept and if they understand and accept traceability, you should be able to count on this person to help you meet project goals.
8. How comfortable are you with ever-changing requirements?
Many development methodologies specify that requirements are locked down at the beginning of a project. Although that is not the case in Agile, it does not mean that requirements are loosey-goosey! The advantage of Agile and its short iterations is that it is easy to quickly recognize that work is not progressing as desired - that what the customer ‘asked for' is not what they ‘wanted' - and the requirements must be changed. Team members should be able to handle such changes on an Agile project. The requirements picture shouldn't be so tied to code, a story card or any other component of work that prevents providing a solution that meets the customer's needs. The general idea is that requirements can change a lot at the beginning of the release, and very little at the end.
9. Did people play multiple roles on your development team?
Here we get back to multidisciplinary teams. What you are really trying to understand from this question is how well an individual would fit into your organization and your style of Agile development. If your organization is one in which individuals select a specialized role (such as Java Developer) as part of their career path, your interview candidate may have difficulty on your team if she is more comfortable working in Agile projects where she has had the ability to play multiple roles (Scrum for example). Conversely, if your candidate's primary experience was developed on projects where roles were clearly defined and individuals did not work in multiple capacities, then he may be uncomfortable in an organization where team members can play any role on a project to achieve its end goal. You must choose the candidate that fits your organization well and is flexible enough to suit the needs of your Agile project implementation. Two particular roles that are more easily interchanged are business analysts and testers, other roles are harder to be "multifunctional" ."
10. What project management tools were used on your project?
This question is more for Agile project managers. Do you have corporate PM tool standards? If so, this question becomes quite important. Agile has a new breed of PM tools including Rally Software, Version One and XPlanner. These tool bear no resemblance to the waterfall PM tools like MS-Project or Clarity. If your candidate is more comfortable using one of these Agile PM tools, try to identify if they will be able to fit their Agile project plans (and issues, milestones, change requests, etc.) into your company's structure.
11. Can you explain the purpose of a burndown chart?
This is more of a question for candidate project managers, although all Agile practitioners should know the answer. A burndown chart is a graph that shows the progress of the team in terms of work "burned through." The work is usually put in terms of a set of "story points" which represent functionality. Once a piece of functionality is coded and tested and reviewed by the user, it is considered to be "burned" and the graph will reflect this. The graph should show a steady movement down until it is clear that the team will have completed the story point backlog by the release date. There is also a variation called a "burnup chart" which is similar to the burndown chart. Again, you want to see how the candidate will link their burndown/burnup chart into