Agile Interview Questions

1) What is the advantage of doing Scrum?

The advantage of doing scrum is that while performing the test

 It minimizes the risk in response to changes made to the system

 It increases ROI ( Return of Investment)
 It improves the process continuously
 It repeatedly and rapidly looks into actual working software
 Anyone can see real working software and continue to enhance for another
iteration

2) How long does a scrum cycle last? Who are involved in Scrum cycle?

Scrum cycle depends on the type of project the team is working on, usually, it ranges
about 2-4 weeks to about a month. In scrum cycle, it includes a

 Scrum master
 Product owner
 Team

3) Explain what is user stories in Scrum?

In scrum, user stories are short, one sentence definitions of a feature or functionality.

4) List out what are the artifacts of Scrum process?

Scrum process artifacts include

 Sprint backlog
 Product backlog
 Velocity chart
 Burn-down chart

5) Explain what is Scrum Sprint?

Scrum project is developed in a series of “sprint”. It is a repeatable and regular work

cycle in scrum methodology during which work is accomplished and kept ready for
review.
6) Explain what the ideal duration is for Sprint, and how it affects the workflow?

Sprint in Scrum usually lasts for 30 days or two weeks. The two-week sprint is preferred
for various reason, first it makes easier for the team to estimate, plan and complete the
work in two weeks. Secondly, it gives enough time to the product owner to change the
priorities more often and allows the team to adapt quickly to the market pressures.

7) Explain what is a product backlog in Scrum?

Before the scrum sprint initiates, product owner review the list of all new features,
change requests, enhancements and bug reports and determines which ones are of high
priorities. If the project is new it includes new features that the new system must provide,
this list of item is referred as Product Backlog. The items that are kept on sprint are
referred as Sprint Backlog.

8) During Scrum meeting what all things are done?

During scrum meeting

 Team analyze how much time they got to complete task during the Sprint
 From product backlog, team takes the first item and breaks into tasks
 Team estimates how long a task will take
 If there is any time left during the sprint, they will move on to the next item on the
product backlog
 Decide the features which have clarity and estimates how many to be scoped for
sprint

9) Mention in brief, what is the role of scrum master in Scrum?

 Removes any obstacles that the team faces during the pursuit of its sprint goals
 Maximizing the productivity of the team
 Making sure that the scripting language used for system testing and unit testing is
written in the same language
 Guides the team and product owner to improve the effectiveness of their practices
  Makes sure that all standard scrum practices are followed

10) What does a scrum burn down chart should consist of?

A scrum burn down chart should consist of

 X-axis that displays working days

 Y-axis that displays remaining effort
 Ideal effort as guideline
 Real progress of effort

11) List out the dis-advantages of Scrum?

 It will be a tricky job for a scrum master to plan, organize and structure a project
that lacks a clear goal
 Daily scrum meeting requires frequent reviews and substantial resources
 A successful project relies on the maturity and dedication of all the team members
 Uncertainty regarding the product, frequent changes and frequent product delivery
remains during the scrum cycle
 It makes all dysfunction visible
 It requires significant change

12) Explain what is scrum of scrum?

Scrum of scrum is used to refer the meeting after the daily scrum. The responsible
person from each team attends the meeting and discuss their work and answer the
questions like

 Since the last meeting, what is the progress of the team?

 What your team is expected to do or should accomplish, before the next meeting?
 What are the obstacles your team faced while completing the task?
 Were you going to allot any of your work to the following team?

13) Explain the term “Increment”?

The term “Increment” is used to refer the total number of the product backlog items
completed during the sprint and all previous sprints. At the end of the sprint, increment
should be in done status; also, it must be in re-useable condition regardless of whether the
product owner is willing to actually release a product or not.

14) Explain what is “Velocity”?

“Velocity” is the total effort a team is capable of in a sprint. The number is obtained by
adding all the story points from the last sprint’s stories. It is a guideline for the team to
understand how many stories they can do in a sprint.

15) Explain what is “Sashimi” and “Impediments”?

 Sashimi: This term is analogous to “done”, it is used to define the specific task
when it is completed. The term used by different team to refer their completed
task status may differ, but should remain same within one team.
 Impediments: Any obstacle that prevent the team members from performing
their work is referred as impediments

16) Explain what is scrum poker or planning poker?

Scrum poker or planning poker is a technique to estimate the relative size of development
goals in software development. It is a way to determine sprint item durations by playing
number cards face down the table, instead of speaking them aloud.

17) Explain what does the burn down charts shows?

Burn down charts is used to track sprint status, they act as an early warning indicators;
they can be useful in highlighting the “lack of progress”. Also, they will highlight the
area where they see redundancy.

18) Mention what is the objective behind holding a Sprint retrospective meeting?

The objective behind Sprint retrospective meeting is to let team members know how
things went during the sprint and discuss possible ways for further improvements for
future sprints.

19) Mention what is the difference between Sprint and Iteration in Scrum?

 Iteration: It is a terminology used to define single development cycle in general

agile methods. It is a common term used in the iterative and Incremental
development process.
 Sprint: It is used to define one development cycle or iterative step in a
specialized agile method referred as Scrum. Sprint is scrum specific, and not all
forms of iterations are Sprints.

20) Explain what is a story point in Scrum?

Each feature in scrum is Story. Story point is an arbitrary measure used by Scrum teams,
and it is a metric used by agile teams to determine the difficulty of implementing a given
story.

21) Explain what velocity in scrum is and how it is measured?

Velocity in a scrum is a measurement of how much the team gets work done in an
iterations or sprint. It is measured by

 V= Number of total story points / One iteration

22)Explain when Scrum cannot be useful?

Ideally scrum is useful to monitor work with 5 to 10 people, who are committed to
achieving the sprint goal. It does not go well with huge groups or team having more
responsibilities. For larger team, scrum can be applied by splitting the team into small
groups and practice scrum.

1. How long were the iterations (or sprints) on the projects you worked on?

Agile project methodology moves at a fast pace and you should already have a good idea
of the length of the iterations for the pending project. Answers of between 1-week to 3-
weeks are ideal. If your candidate has worked on Agile projects which have long
iterations (4 weeks or longer), or wildly variable-length iterations, it will make sense to
determine if this person is comfortable with the iterations as defined for your project. A
steady set of fixed-length iterations that are fairly short is best. The theory that big
companies need longer iterations is not based in fact. We’ve done many big company
projects in the 1 to 2 week iteration range.

2. Are you a Certified Scrum Master (CSM)? If so, how do you view the way Scrum
projects need to be organized?

Often we use certifications as a golden way to qualify candidates. But be somewhat

careful with people who have gone through the Certified Scrum Master (CSM) training.
The goal here is to make sure that your project team member is comfortable with
structure as each iteration progresses. Is she comfortable working with a project manager,
or communicating to a team lead? Working inside a large corporation, you personally
might feel that a project manager or team lead position is required on all but the smallest
effort. But certain Agile consultants will insist that project managers are no longer
necessary under Agile because teams will "self organize." Steer clear of these candidates
unless that is clearly the direction you want to go. Does your organization have defined
roles and career paths like project manager, tester, business analyst, etc.? Do you have a
strategy for muddying those career paths for the employees you bring onto this Agile
initiative? If so, great. If not, avoid the candidates who tell you there is no alternative to
self-organization.

If the person is not a CSM, you may still encounter these issues, so pursue the line of
questioning either way.
NOTE: There is nothing systemically wrong with self-organization, but as a hiring
manager, you need to know what your own strategy is for Agile adoption and then hire
accordingly. I personally haven’t met many corporate managers who are terribly
comfortable with self-organizing teams.

3. Did you use automated test tools on your projects? Explain how that worked.

Agile project team members should have experience (or at the very least, the desire) to
use automated testing tools for regression and performance testing of each iteration. At
the end of each iteration you want to have something that your customer/client can "see."
Automated testing allows quick identification and isolation of development defects as
well as the ability to test development work completed in previous iterations. Expect the
candidate to talk about automated regression testing, continuous integration and testing
and even performance testing techniques and tools. Also expect them to discuss the need
for manual testing as well as automated testing, due to the ever-changing nature of the
code base in Agile.

4. Have you done continuous integration on a project before? Describe.

Here you want to get a pretty detailed explanation of how the candidate has used
continuous integration on previous projects. Continuous integration is a set of automated
build, integration and test steps that executes against the code base in a configuration
management repository. For instance, if you were using Java and CVS, the CVS
repository would have a set of triggers that automatically built, integrated and unit tested
the code often, perhaps each night, perhaps a few times a week, or even every time
someone checked in new code. Each of these is a valid continuous integration story.

5. Did your iterations overlap? For instance, were the testers still testing Iteration 6
while Iteration 5 was being designed/developed?

There are many views of how iterative/incremental projects should run under Agile.
Overlapping iterations is certainly one strategy. The danger is to pay attention to the
candidate if they say that "iterations should never overlap." This may tell you that the
candidate is used to having what is called "multidisciplinary teams." This type of team
consists of a set of generic team members who all have the skills and enthusiasm for
requirements, design, coding and testing and who each participate in those activities
almost equally. If your company has defined roles (business analyst, test analyst, etc.)
and career paths then this candidate may have a tough time fitting into your structure.
They will want BAs to code and testers to do design. Is that okay? It is your decision.
Again, nothing wrong with multidisciplinary teams, but your organization must be able to
handle the change if you decide to go that way.

6. Have you used story cards or use cases? Explain how that worked for the team.

Often, Agile projects are associated with the use of story cards. However, our goal is to
simply understand if our potential team member is comfortable implementing a project
(designing, developing, testing, etc) with business information which has been
documented in some way. The requirements (story cards or use cases or a combination of
both) should have enough information to provide guidelines for developing and testing
and also allow the development team to come up with a creative and effective solution.
By asking this question, you want to understand if your potential team member is
comfortable working with requirements in a structured development environment (versus
brief summaries from which the developers build code). Again, this is a matter of
matching the Agile candidate’s experience with your organization’s needs.

7. How did you manage traceability of the requirements to testing?

The point here is to make sure testing goes all the way back to requirements for
validation. Not only is it important to test that the functionality a developer has created
during an iteration actually functions, it is also important to determine if it functions the
way the business wanted it to function. Does it meet the requirements defined in the story
card / use case? Your team members should understand 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. It shouldn’t be
so tied to code, a story card or any other component of work that prevents providing a
solution which 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 which 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 tools 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 people
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" that works the same way but can handle scope changes more easily than
the burndown variety. Again, you want to see how the candidate will link their
burndown/burnup chart into your overall project management structure.

12. What does project velocity mean?

This is a PM question, but most Agile people should know the answer. Project velocity is
the rate at which a team is "burning" through story points, so a possible velocity might be
"30 story points per iteration." That means that so far, the team has been able to identify,
code and test 30 units of functionality (story points) in an average iteration and can
expect to do about that much in future iterations, giving a fairly good view towards what
can be accomplished by a release date.

Hopefully, these twelve questions can be a good start for your qualification process in
bringing in new Agile consultants or candidate employees. Our hope is that you can build
a highly-qualified team that will fit in well with your corporate development process,
culture and PM standards.

Q: What are the three main roles in Scrum?

A: The Scrum team consists of three main roles:

 Product Owner: Manages the product backlog. PO is the voice of the business
and create new features to be developed for the application.

 Scrum Master: Responsible for managing the sprint, remove any impediments
and keeps track of the progress of the project.
 Scrum Team itself: Composed of developers, designers and QA. This forms the
team which is responsible for delivering high quality software.

1. Strength vs Weakness
 You should choose a strength that is really related to the job you apply for,
a strength that characterize good software developer/tester/project manager. To
such belongs analytical thinking, problem solving, mathematical skills, ability
to work quickly, detail-oriented personality and some other related strengths.
 When talking about your weaknesses, choose something that does not
matter. For example, managing other people or struggling to communicate
with non-IT guys, is not something that should bother a tester heavily. Or you
can even pick a weakness that some interviewers consider as a strength, for
example being impatient.
 Then you should elaborate on it explaining the interviewers what you do to
further improve on your strengths and eliminate the impact of your
weaknesses, at least to certain extend. That is what they want to hear from an
ideal job applicant.

 Sample answers
 I really like to test software and therefor my motivation is very high in
job. I can work quickly and act responsively, what I believe is crucial
for agile development. On the other hand, I am sometimes impatient,
what may cause troubles to other colleagues. However, I am aware of
this weakness and always remind it to myself to stay patient in job.
 My analytical thinking and problem solving abilities are exceptional. I
work on it constantly, solving new problems and learning new
technologies. On the other hand, I am not very good in managing other
people and leading teams. I tried it in the past, but I was not good at it.
I hope to improve on it, but it’s not easy.

2. In what does the agile testing(development) methodology differs from the

other testing (development) methodologies?
Anytime applying agile methodology, the testers (developers) ensure that the
whole process of testing (development) is broke into as small steps as possible
and just a small unit of code is tested (developed) in each of this steps. The team
of testers (developers) is communicating consistently the results of their work,
and change the short term strategy and even the development plan on the go,
based on the results of agile testing. Agile methodology encourages flexible and
rapid response to change which should lead to a better end result.
3. Can agile methodology be applied also in other than software testing and
development projects?
While asking these sort of questions, employers try to recognize if you really
understand the benefits of this methodology and can see a practical application in
various areas of business. To state that this methodology can be, and maybe even
 should be, applied in all the instances and test cases where we have insufficient
entry data, or work in an unknown area, or simply work within a small team, or
where many unpredictable variables take place, is a good answer. It is in fact used
quite commonly in bio-medicine, biochemistry or physics. Anyway, it could be
used in many other areas too. Just let your imagination work and you’ll find a
good answer…
4. Are you able to name five main characteristics of agile methodology?
Every person can approach agile methodology from a different angle. The
employer tries to find out what your opinion is, and if it is the one they are
looking for.
So in fact, the right answer really depends on your point of view. However, if you
look for characteristics that are usually “positive” for the company, you should do
well with things like cross-functional team composition, face-to face
communication, solving problems immediately after these are identified, working
solution as a primary metric of progress. If you do not like our suggestions, you
will have to figure out something on your own.
5. Describe a situation when you personally used the agile methodology (or was
a part of a team that used it).
This question is very important. One little experience is more useful than the
entire book of theory. Before the interview, think carefully about your own
application of agile methodology. If you can not find any example in your
professional life, try to find it in personal life. Think about it in advance, prepare a
situation you will talk about later and focus on the positive results associated with
the implementation of AM in your project. Doing it, you should be well prepared
for all these practical questions. We wish you good luck!
6. 1. What is Black box testing?
Answer: Black box testing is the testing of requirements and functionality without
knowledge in internal content. Inputs are fed into the system and outputs are
determined expected or unexpected
7. 2. What is white box testing?
Answer: White box testing is testing based on knowledge of the internal logic
(algorithms) of an application’s code. Its an approach that attemptes to cover the
software’s internals in detail. White box testing is also known as ‘glass box
testing’, ‘clear box testing’ , ‘transparent box testing’ and ‘structural testing’
8. 3. What is grey box testing?
Answer: Grey box testing uses a combination of black and white box testing.
Grey box test cases are designed with knowledge of the the internal logic
(algorithms) of an application’s code but the actual testing is performed as black
box. Alternately a limited number of white box testing is performed followed by
conventional black box testing
9. 4. What is unit testing
Answer: Unit testing is the testing of the smallest units of code such as functions.
Typically unit testing is performed by the developer and not by testers. It requires
knowledge of the internal program’s organisation and code. Unit testing may not
be easily performed as independent testable components may be difficult to
isolate for testing. Some unit testing may require building a driver module to be
 built. Typically unit testing documentation is minimal if it is documented at all.
Unit testing is also known as component testing
10. 5. What is integration testing ?
Answer: Integration testing consists of integrating components (units) of a
software design to verify that the component are working well together. Typically
tested software modules (units) are integrated progressively until the entire
integrated system (software design) is complete
11. 6. What is system testing?
Answer: System testing verifies that an integrated system (independent of third
party systems) meets requirements.
12. 7. What is System integration testing?
Answer:System integration testing verifies the satisfactory integration of the
completed and tested system with external systems (if any).
13. 8. What is regression testing?
Answer: Regression testing consists of testing for software regressions. Typically
regression testing is performed after changes have been made to a preciously
released version of the software. The point is to discover any knock on effects
(side effects) of having modified the software. Modifications to a system can
produce collateral damage such as conflicts within the system, performance issues
or reemergence of old previously closed bugs.
14. 9.What is acceptance testing?
Answer: Acceptance testing is typically by the customer performed usually on site
on their designated test system. Acceptance testing is also known as user
acceptance testing (UAT). Typically this is the last phase of testing before the
software is released to the client,
15. 10. What is a UAT?
Answer: User acceptance testing see Acceptance testing
16. 11. What is a trace-ability matrix?
Answer: A trace-ability matrix is a document cross referencing requirements and
test points in a test case. The point is the have sufficient test cases to cover all of
the requirements
17. 12. What is a Moscow list?
Answer:MoSCoW is an acronym for Must, Should, COuld, Would. It essentially
is a priority checklist. When discussing system requirements with the users a
MoSCoW list may be used to help prioritize requirements to determine which are
most critical.
18. 13. What is a smoke test?
Answer:A smoke test is a quick and dirty test to determine quickly the status of a
system. It is used to reveal simple failures severe enough to reject a prospective
software release. The smoke test once successful is followed by further testing,
19. 14. What is stability testing?
Answer:Stability testing is performed to determine if a software system is stable
over time. Typically a period of time is targeted. A memory leak is a an example
of the type of problem that could destabilize a software system over time.
20. 15. What is Usability testing?
Answer:Usability testing consists of testing that the user interface (GUI) is simple
to understand , intuitive , consistent and optimized for power users.
21. 16. What is security testing?
Answer:Security testing consists of determining if the system authentication is
functional, the system protects data and the system is resistant to hackers
22. 17. What is Scalability testing?
Answer: Scalability testing consists of determining if the system can be scaled up
in terms of load supported, the number of transactions, the data volume etc. This
can also be classified as performance testing and non-functional testing
23. 18. What is Reliability testing?
Answer: Reliability testing consists of determining the ability of a system or
component to perform its required functions under stated conditions for a
specified period of time. This can also be classified as performance testing and
non-functional testing
24. 19. What is compatibility testing?
Answer: compatibility testing consists of determining the application’s
compatibility with the computing environment. Is the application compatible with
the hardware (PC, Mac, IBM 360) , peripherals (printer, modem, scanner),
operating system (UNIX, Linux, Windows 7, Windows vista), database (oracle,
sql server), browser(Firefox,Opera IE) etc.. This can also be classified as non-
functional testing
25. 20. What is Concurrency testing?
Answer: Concurrency testing consists of determining if the system can
successfully handle concurrent threads and users. Testing with concurrent users
might also include testing concurrent access to a database row.
26. 21. What is Code coverage ?
Answer: Code coverage consists of determining percentage of a system’s code
that is being verified by a test(s).
27. 22. What is a Sprint ?
Answer: A Sprint is the basic unit of development in Agile Scrum development. It
is a time box of effort directed towards a specific goal which is a subset of a
greater effort and goal. A typical sprint lasts about 3-4 weeks
28. 23. What is a Test stub ?
Answer: A test stub is an bit of code that replaces an undeveloped or fully
developed component within a system being tested. The test stub is built such that
it mimics the actual component by generating specific known outputs. The stub
can be used as a substitute for the actual (fully developed) component for testing
purposes. The stub can also be used during testing to isolate system components
and troubleshoot problems. A test stub is also known as a test double.
29. 24. What is a Test-Driven Development (TDD) ?
Answer: Test-Driven Development (TDD) is a development methodology
whereby the developer writes a unit test as a starting point and then writes code
that will allow the test to pass. The development of the entire system proceeds one
test at a time. Further Info: Test-Driven Development (TDD)
30. 25. What is a story board ?
Answer: A Story board is a visual representation of a software project’s progress.
There are generally four columns ‘To do’, ‘In Progress’,'Test’,” and ‘Done’.
Different colored post It notes are placed in each column indicating the progress
of individual development items. A story board is typically used in agile
development.

31. 26. What is a Release candidate ?

Answer: A Release candidate is a build or version of a software that can be
released to production. Further testing such as UAT may be performed on this
version of the product.
32. 27. What is Re-factoring ?
Answer: Re-factoring is modifying existing code to improve its performance,
readability,extensibility etc. The code’s functionality remains as is .
33. 28. What is an epic ?
Answer: An epic is an agile term for a customer described software feature that is
itemized in the product backlog. Epics are subdivided into stories.
34. 29. What is functional test ?
Answer: A functional test is a type of black box test that based on the
specifications of the software object being tested. Functions are tested by
inputting known values and examining the output
35. 30. What is a business facing test ?
Answer: A business facing test can be explained in terms recognizable the subject
matter expert using words from the business domain. Example: when an item is
placed in cart the sales tax is automatically added. Technology facing tests in
contrast can be explained in technical terms not necessarily understood by the
subject matter expert. When an item is purchased a cookie is set on the client
computer.
36. 31. What is a technology facing test ?
Answer: See business facing test .
 37. 32. What is a use case ?
Answer: A use case is a software modeling technique. A description or a diagram
(use case diagram) of a user’s (actor) useful actions on a theoretical software
system is created for the purpose of modeling the the software . A useful action is
one that achieves a specific goal. Further Info: Use case

38. 33. What is UML ?

Answer: UML is an acronym for Unified modeling language. UML is a graphical
Object oriented software modeling language.The visual models or artifacts
include but are not limited to: sequence diagram, activity diagram, class diagram,
object diagram, use case diagram, state machine diagram Further Info: UML
39. 34. What is a boundary testing ?
Answer: Boundary testing also known as boundary value analysis is verifying the
upper (and just above) and lower (and just below) limits of the input domain. A
boundary value analysis test case would input into a function, values that meet the
above mentioned criterion
40. 35. What is a boundary value analysis?
Answer: See Boundary testing.

One hundred and one Agile development job interview

questions (and answers)
Filed Under: Agile, Software job interview questions by Jet Ford — 1 Comment
June 28, 2011

1. What is a Sprint ?
Answer: A Sprint is the basic unit of development in Agile Scrum development. It is a
time box of effort directed towards a specific goal which is a subset of a greater effort
and goal. A typical sprint lasts about 3-4 weeks

2. What is a Test stub ?

Answer: A test stub is an bit of code that replaces an undeveloped or fully developed
component within a system being tested. The test stub is built such that it mimics the
actual component by generating specific known outputs. The stub can be used as a
substitute for the actual (fully developed) component for testing purposes. The stub can
also be used during testing to isolate system components and troubleshoot problems. A
test stub is also known as a test double.

3. What is a Test-Driven Development (TDD) ?

Answer: Test-Driven Development (TDD) is a development methodology whereby the
developer writes a unit test as a starting point and then writes code that will allow the test
to pass. The development of the entire system proceeds one test at a time. Further Info:
Test-Driven Development (TDD)

4. What is a story board ?

Answer: A Story board is a visual representation of a software project’s progress. There
are generally four columns ‘To do’, ‘In Progress’,'Test’,” and ‘Done’. Different colored
post It notes are placed in each column indicating the progress of individual development
items. A story board is typically used in agile development.

5. What is a Release candidate ?

Answer: A Release candidate is a build or version of a software that can be released to
production. Further testing such as UAT may be performed on this version of the product.

6. What is Re-factoring ?
Answer: Re-factoring is modifying existing code to improve its performance,
readability,extensibility etc. The code’s functionality remains as is .

7. What is an epic ?
Answer: An epic is an agile term for a customer described software feature that is
itemized in the product backlog. Epics are subdivided into stories.
8. What is the Agile manifesto?
Answer: The following is the Agile manifesto: We are uncovering better ways of
developing software by doing it and helping others do it. Through this work we have
come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on

the right, we value the items on the left more.

41.