1) As a tester what should be your approach when requirements change

continuously?

When requirement keeps changing, continuously agile tester should take following
approach

 Write generic test plans and test cases, which focuses on the intent of the
requirement rather than its exact details
 To understand the scope of change, work closely with the product owners or
business analyst
 Make sure team understand the risks involved in changing requirements
especially at the end of the sprint
 Until the feature is stable, and the requirements are finalized, it is best to wait if
you are going to automate the feature
 Changes can be kept to a minimum by negotiating or implement the changes in
the next sprint

2) List out the pros and cons of exploratory testing (used in Agile) and scripted
testing?

Pros Cons
- It requires less preparation-
Easy to modify when - Presenting progress and
Exploratory requirement changes Coverage to project
Testing
– Works well when management is difficult
documentation is scarce
- Test preparation is usually
- In case testing against legal time-consuming- Same steps
Scripted are tested over and again
or regulatory requirements it
Testing
is very useful – When requirement changes it
is difficult to modify

3) Explain the difference between Extreme programming and Scrum?

Scrum Extreme Programing (XP)

- Scrum teams usually have to work
in iterations called sprints which
usually last up to two weeks to one
month long
- Scrum teams do not allow change
into their sprints
- In scrum, the product owner
prioritizes the product backlog but
the team decides the sequence in
which they will develop the backlog
items
- XP team works in iteration that
last for one or two weeks
- XP teams are more flexible and
change their iterations
- XP team work in strict priority
order, features developed are
prioritized by the customer
 - Scrum does not prescribe any - XP does prescribe engineering
engineering practices practices

4) What is an epic, user stories and task?

 Epic: A customer described software feature that is itemized in the product

backlog is known as epic. Epics are sub-divided into stories
 User Stories: From the client perspective user stories are prepared which
defines project or business functions, and it is delivered in a particular sprint as
expected.
 Task: Further down user stories are broken down into different task

5) Explain what is re-factoring?

To improve the performance, the existing code is modified; this is re-factoring. During re-
factoring the code functionality remains same

6) Explain how you can measure the velocity of the sprint with varying team
capacity?

When planning a sprint usually, the velocity of the sprint is measured on the basis of
professional judgement based on historical data. However, the mathematical formula
used to measure the velocity of the sprint are,

 first – completed story points X team capacity: If you measure capacity as a

percentage of a 40 hours weeks
 Second – completed story points / team capacity: If you measure capacity in
man-hours
For our scenario second method is applicable.

7) Mention the key difference between sprint backlog and product backlog?

Product backlog: It contains a list of all desired features and is owned by the product
owner

Sprint backlog: It is a subset of the product backlog owned by development team and
commits to deliver it in a sprint. It is created in Sprint Planning Meeting

8) In Agile mention what is the difference between the Incremental and Iterative
development?

Iterative: Iterative method is a continuous process of software development where the

software development cycles are repeated (Sprint & Releases) till the final product is
achieved.

Release 1: Sprint 1, 2… n

Release n: Sprint 1, 2….n

Incremental: Incremental development segregates the system functionality into

increments or portions. In each increment, each segment of functionality is delivered
through cross-discipline work, from the requirements to the deployment.

9) Explain what is Spike and Zero sprint in Agile? What is the purpose of it?

Sprint Zero: It is introduced to perform some research before initiating the first sprint.
Usually this sprint is used during the start of the project for activities like setting
development environment, preparing product backlog and so on.

Spikes: Spikes are type of stories that are used for activities like research, exploration,
design and even prototyping. In between sprints, you can take spikes for the work
related to any technical or design issue. Spikes are of two types Technical Spikes and
Functional Spikes.

10) What is test driven development?

Test driven development or TDD is also known as test-driven design. In this method,
developer first writes an automated test case which describes new function or
improvement and then creates small codes to pass that test, and later re-factors the new
code to meet the acceptable standards.

11) Prototypes and Wireframes are widely used as part of?

Prototypes and Wireframes are prototypes that are widely used as part of Empirical
Design

12) Explain what is Application Binary Interface?

Across different system platforms and environments a specification defining
requirements for portability of applications in binary form is known as Application Binary
Interface

13) Explain in Agile, burn-up and burn-down chart?

To track the project progress burnup and burn down, charts are used

Burnup Chart: It shows the progress of stories done over time

Burndown Chart: It shows how much work was left to do overtime

14) Explain what is Scrum ban?

Scrum ban is a software development model based on Scrum and Kanban. It is specially
designed for project that requires frequent maintenance, having unexpected user stories
and programming errors. Using these approach, the team’s workflow is guided in a way
that allows minimum completion time for each user story or programming error.

15) What is story points/efforts/ scales?

It is used to discuss the difficulty of the story without assigning actual hours. The most
common scale used is a Fibonacci sequence ( 1,2,3,5,8,13,….100) although some
teams use linear scale (1,2,3,4….), Powers of 2 (1,2,4,8……) and cloth size (XS, S ,M,L,
XL)

16) Explain what is tracer bullet?

The tracer bullet is a spike with the current architecture, the current set of best practices,
current technology set which results in production quality code. It is not a throw away
code but might just be a narrow implementation of the functionality.

17) What is a test stub?

A test stub is a small code that replaces an undeveloped or fully developed component
within a system being tested. Test stub is designed in such a way that it mimics the
actual component by generating specifically known outputs and substitute the actual
component.

18) What are the differences between RUP (Rational Unified Process) and Scrum
methodologies?

RUP SCRUM
- Formal Cycle is defined across four
phases, but some workflows can be - Each sprint is a complete cycle
concurrent
- No end to end project plan. Each next
- Formal project plan, associated with
iteration plan is determined at the end
multiple iterations is used.
of the current iteration
 - Scope is predefined ahead of the
project start and documented in the
scope document. During the project,
scope can be revised.
- Artifacts include Scope Document,
formal functional requirements package,
system architecture document,
development plan, test scripts, etc.
- Recommended for long term, large,
enterprise level projects with medium to
high complexity
- It uses a project backlog instead of
scope scrum
- Operational software is the only formal
artifacts
- Recommended for quick
enhancements and organization that
are not dependent on a deadline

19) Why Continuous Integration is important for Agile?

Continuous Integration is important for Agile for following reasons

 It helps to maintain release schedule on time by detecting bugs or integration

errors
 Due to frequent agile code delivery usually every sprint of 2-3 weeks, stable
quality of build is a must and continuous integration ensures that
 In helps to maintain the quality and bug free state of code-base
 Continuous integration helps to check the impact of work on branches to the main
trunk if development work is going on branches using automatic building and
merging function

20) What testing is done during Agile?

The primary testing activities during Agile is automated unit testing and exploratory
testing.

Though, depending on project requirements, a tester may execute Functional and Non-
functional tests on the Application Under Test (AUT).

1. What’s the benefit of using Agile over conventional

Waterfall methodology for developing software?
Benefit of Agile Methodology

 It provides greater visibility to stakeholder from the start of the sprint, which in
turn provide early feedback and ensures project success.
 Risks are greatly reduced and handled in better way in agile.
 Products can be delivered early.
 Clients are more involved and have greater satisfaction.
 Greater agility, changes could be incorporated early.
 Development could be started early.

2. What are the different meetings in Agile? What is purpose of Release Planning,
Sprint Planning meetings, Scrum Meeting, Sprint Review Meeting, Retrospection?

Release Planning
 In this release plan is prepared, which include list of features that needs to be delivered,
release date of software into Production, number of iterations/sprints for that release etc.

Spring Planning
In this product Owner presents the set of features he would like and the team asks questions
to understand the requirements in sufficient detail to enable them to commit to delivering the
listed features in sprint.

Daily Scrum Meeting

Daily Scrum Meeting is for answering the following 3 questions:
1. What have you done since yesterday’s meeting?
2. What are you going to get done today?
3. What obstacles do you need to be removed?

Sprint Review
It is demonstration of the new features the team has completed during the sprint; it is used to
gather early feedback.

Sprint Retrospection
It follows immediately after the sprint review. It is focused on the process, the way in
which the Scrum team is working together, including their technical skills and the software
development practices and tools they are using.

In this meeting team discuss on following points:

1. What went wrong?
2. What went well?
3. What can be improved?
3. How you do Estimation in Agile? How to estimate using Planning Poker?

In Agile often estimation is done using planning poker:

 Each member of team is given deck of card which contains stories points in
Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13...
 Scrum Master lists the user stories and provides brief overview of them. Team
discusses and clarifies any questions/risks.
 Each team member privately assigns a card representing his estimate of the size for
the user story.
 Later on all estimates are revealed and people having low estimates and high
estimates need to provide justification for the same and after discussion within team
story point is finalized for use story. Same is repeated for all user stories.

4. What is Continuous Integration and why it is important for Agile? What are the
software/tools available for the same?

Check this Continuous Integration

5. What is difference between Product backlog & Sprint Backlog?

Product backlog is owned by the product owner, which contains list of all desired features.
 Sprint backlog is created in Sprint Planning Meeting. It is subset of product backlog which is
owned by development Team, who commits it to deliver in a sprint.
6. What is difference between Epic, User stories & Tasks? Who should create User
stories & Task?

User Stories defines business requirement from the client perspective and it is supposed
to be delivered in particular sprint.
Task: User Stories are further broken down into different task from technical perspective.
Epic is a group of related User Stories, or it is large use story which cannot be completed
in single Sprint.
User stories should be created by Product Owner as these are written from client
perspective. Tasks should be created by someone from Development Team who is aware
about them from technical perspective.

7. What is Pair Programming? What’s the benefit of that?

As per Wiki Pair programming is defined as:

“Pair programming is an agile software development technique in which two programmers work together at one
workstation. One, the driver, writes code while the other, the observer or navigator, reviews each line of code
as it is typed in. The two programmers switch roles frequently”
Benefits of Pair Programming:

 It helps in business and technical knowledge transfer within the team.

 It improves code quality and helps in building better design.
 In short term there may be loss of productivity but it increase productivity of resource due to gain
in business or technical knowledge.

8. What is TDD (Test Driven Development)?

As per Wiki TDD is defined as:

Test-DrivenDevelopment (TDD) is a software development process that relies on the repetition of a very short
development cycle: first the developer writes an (initially failing) automated test case that defines a desired
improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors
the new code to acceptable standards.

9. What do you mean by Iterative and Incremental Development in Agile?

Iterative: In iterative development, software development is done in repeated cycles

(Releases & Sprints).In each iteration planned use stories are designed, developed, tested and
deployed for customer's feedback.

Release 1: Sprint 1, 2…n

Release 1: Sprint 1, 2…n
..
Release n: Sprint 1, 2…n

Incremental:
As per Wiki Incremental Development defined as:
 “Incremental development slices the system functionality into increments (portions). In each increment, a slice
of functionality is delivered through cross-discipline work, from the requirements to the deployment. The unified
process groups increments/iterations into phases: inception, elaboration, construction, and transition.”

10. What is Burn-Down or Burn-Up Chart in Agile?

Burn Up and Burn Down charts are used to track project progress.
Burnup Chart shows progress of stories done over time. X Axis: Time, Y Axis: no. of user
stories completed.
Burndown Chart shows how much work was left to do over time. X Axis: Time, Y Axis:
no. of user stories remaining.

11. What do you mean by Velocity in Agile?

As per Wiki Velocity is defined as:

“The velocity is calculated by counting the number of units of work completed in a certain interval, the length of
which is determined at the start of the project”
Velocity is used in Agile to calculate the no. of stories that can be delivered in particular sprint based on previous
delivery.

12. What does Task board indicates in Agile?

Task board is used to track progress in agile. Generally it has following columns:
Use Story: Use Story under consideration for current sprint.
To Do: Tasks that needs to be picked up.
In Progress: Tasks that are currently in progress.
To Verify: Tasks that needs to verified/tested.
Done: Tasks that are completed.
Frequently used agile methodology interview questions
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.

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…

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.

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!

Sample Agile Foundation Examination Questions:

1. Which of the following best describes the approach for determining the iteration (timebox)
length?

A. Iterations (timeboxes) should always be 30 days

B. The team determines iteration (timebox) length by dividing the total number of story points
by the average velocity of the team
C. Iterations (timeboxes) should always be two weeks
D. The team should agree on the length of the iteration (timebox), taking the size and
complexity of the project into consideration
2. Which of the following is a characteristic of an Agile leader?
A. Task focused
B. Process oriented
C. Supportive
D. Disengaged
3. Who is responsible for prioritizing the product backlog?
A. Product Owner
B. Project Manager
C. Lead Developer
D. Business Analyst
4. What are the advantages of maintaining consistent iteration (timebox) length throughout the
project?
A. It helps to establish a consistent pattern of delivery
B. It helps the team to objectively measure progress
C. It providea a consistent means of measuring team velocity
D. All of the above
5. Tracking project issues in an Agile project is the primary responsibility of the…
A. Tester
B. Project Leader
C. Functional Manager
D. Developer Sample Questions with Answers for Web Revised Jan 2013 v0 4 3 22 January 2013 Author D J Tudor
6. Why is it important to trust the team?
A. High trust teams do not have to be accountable to each other
B. High trust teams do not require a user representative
C. The Project Manager does not then have to keep a project schedule
D. The presence of trust is positively correlated with the team performance
7. An effective workshop facilitator will always ...
A. Involve the whole project team in all project workshops
B. Agree the process and participants of the workshop with the workshop owner before the
workshop
C. Involve only those team members who will commit to doing further work after the workshop
D. Act as a proxy for any invited participant who is unable to attend the workshop on the day
8. Which of the following best represents the Agile approach to planning?
A. Planning is not part of an Agile approach, because Agile is exploratory
B. Planning should be done in detail at the outset of a project and not revisited
C. Planning should involve the whole team, not just the Project Manager
D. Planning should all be done by the Project Manager
9. Who should define the business value of a Feature within an Agile project?
A. The individual end-users
B. The Product Owner
C. The Business Analyst
D. The Business Sponsor
10. If a timebox (iteration) plan needs to be reprioritised in a hurry, who should re-prioritise?
A. The developers alone (they know what the customer wants)
B. The Product Owner (the developers would only choose the easy things as top priority)
C. The Project Leader (they can give an independent, pragmatic view)
D. The whole team including Product Owner and developers (together they can consider both
business value and practicality)
Sample Questions with Answers for Web Revised Jan 2013 v0 4 4 22 January 2013 Author D J Tudor
11. What is the effect of having a large visible project plan on a wall?
A. It removes the need to create any other reports for management
B. It continuously communicates progress within the team and to other stakeholders
C. It allows the Project Manager to allocate tasks to specific team members
D. It is restrictive, as it does not allow the team to innovate and change
12. How should work be allocated to the team in an Agile project?
A. The Team Leader (Scrum Master) should allocate specific tasks to individuals
B. Tasks should be randomly allocated to team members, using Planning Poker
C. Team members should self-select tasks appropriate to their skills
D. The most complex tasks should be allocated by the Team Leader (Scrum Master)

13. What should the developers do if the customer representative is repeatedly too busy to be
available?
A. Continue the work, record the assumptions and ask the customer later for input.
B. Send the customer a written warning that the end product will be completed on time, but
may not meet their needs
C. Allow the Business Analyst to take on the role of Proxy Customer Representative
D. Draw the problem to the attention of the Scrum Master (Team Leader)

14. Which one of the following is a key feature of documentation that you would expect to find
in an Agile project?
A. System documentation created at the end of each increment, at the start of the deployment
B. User Stories held in a spreadsheet or specialist database, where full details of user
conversations are recorded for future purposes, like handover to maintenance or support
C. User Story cards containing only enough detail for planning and development, which will
need to be supplemented by further face-to-face conversations
D. No written documentation, as all good communication is face-to-face

15. When handling team dynamics, the Agile Leader should …

A Empower the team members, within appropriate limits
B. Encourage an environment of competition and personal advantage
C. Give clear directives to the team about what they should do and how
D. Expect team members to be proactive and each work to their own priorities and objectives
Sample Questions with Answers for Web Revised Jan 2013 v0 4 5 22 January 2013 Author D J Tudor
16. Which one of the following statements is correct regarding acceptance of any deliverables on
an Agile Project?
A. The team should allow only senior managers to sign off deliverables
B. The team should get acceptance of project deliverables from the appropriate stakeholders
at least at the end of every timebox / iteration
C. The team should get acceptance of project deliverables from the users during a UAT phase at
the end of the project
D. Acceptance of any particular deliverable on the project is gained from all stakeholders at the
same time.

17. Which one of the following statements is correct regarding quality of deliverables from an
Agile Project?
A. The products produced by an Agile project should be cheaper than those produced by any
other approach, but quality will suffer
B. The products will be more expensive than by any other approach but will be top quality
C. The products will be fit for purpose, but may not do what the customer wanted
D. The products will be of appropriate quality, as guided by the customer representative
involved throughout the development process

18. What is the Agile approach to doing design early in a project?

A. A big design up front is always a good idea
B. Just enough design up front gives a good foundation to start from and helps to mitigate
risk, without wasting unnecessarily time
C. No design up front is the best approach as most of the fun of a project is in discovery of the
unexpected
D. Design has no place in an Agile project

19. An Agile approach advocates which of the following approaches?

A. Get something “quick and dirty” delivered, to save time
B. Get something simple released as quickly as possible
C. Get something business-valuable delivered as quickly as possible, consistent with the right
level of quality
D. Get something delivered once it has been fully documented and the documentation has been
signed off as complete

20. Which of these best describes the Agile approach to team-working?

A. The team should plan to work a small amount of overtime regularly throughout the project
B. The team should expect to work longer hours towards the end of the sprint (timebox), in
order to deliver all that was committed to
C. The team should strive for a sustainable pace and a normal working week
D. The team will “burn out” if they have to work overtime for more than two sprints (timeboxes,
iterations) in a row
Sample Questions with Answers for Web Revised Jan 2013 v0 4 6 22 January 2013 Author D J Tudor
21. Which one of the following statements about workshops is true for Agile projects?
A. All project stakeholders should attend requirements workshops
B. Retrospectives are only run at the end of a project
C. It is best if the Project Manager facilitates the project’s workshops
D. An independent facilitator will manage the structure of a facilitated workshop but not
input to the content

22. Which one of the following is an important feature of the daily stand-up / wash up / Scrum
meeting?
A. Everyone is expected to stand for the whole time, to keep the meeting short
B. The meeting must be kept short and well structured
C. The meeting should ensure that it is clear to all which team members are not performing
D. No-one is allowed to leave the stand-up meeting until all problems raised have been solved

23. Who should attend the stand-up meetings?

A. Sponsor and Executive Management only
B. Project Manager and Technical Leads only
C. Project Leader and Customer Representatives only
D. The entire team

24. One of the development stages you would expect to see a team go through is:
A. Storming
B. Warming
C. Cloning
D. Yawning
25. When estimating is done for a project, the developers should:
A. Be fully involved in the estimating process
B. Be in total control of the estimating process
C. Be consulted after the Team Leader (Scrum Master) has made the estimates for the team’s
work
D. Not make estimates unless velocity is already known
26. During an iteration (sprint) (timebox) the developers should be:
A. Able to contact the customer to clarify aspects of the work
B. Completely uninterrupted by the customer
C. In twice-daily contact with the customer
D. Able to work without needing to disturb the customer Sample Questions with Answers for Web Revised
Jan 2013 v0 4 7 22 January 2013 Author D J Tudor
27. The end result of an Agile development is:
A. A product of a professional quality which fits the business need
B. A product of almost as good a quality as a Waterfall development
C. A product which is barely sufficient for its purpose and deliberately not maintainable
D. A technically-perfect, re-factored solution
28. An Agile customer …
A. Must have a thorough understanding of Agile techniques, for Agile to work
B. Will always receive lower-quality products than their non-Agile counterparts
C. Will typically get business value delivered early and often
D. Will need to understand the technical aspects of development, to contribute effectively
29. An Agile team …
A. Is self-organizing, with each member having the same technical skills
B. Collaborates and supports its team members
C. Ensures that weak members of the team are allocated the simpler tasks
D. Ensures blame is allocated fairly
30. The Agile process …
A. Encourages the team to meet regularly
B. Has no meetings
C. Has lengthy reporting requirements
D. Has no reporting requirements
31. The Agile Leader …
A. Should allocate tasks to the team members each day at the stand-up meeting
B. Should involve the team in their own work-allocation
C. Should give detailed work-plans to the team each day
D. Should direct the work of the team, if they are inexperienced
32. What is Kan Ban?
A. A list of activities banned by the team, in relation to Team Norms
B. The set of Can Have stories for a project
C. A visible chart of work to do, work in progress and work done
D. A graph of tasks partially-completed by the team Sample Questions with Answers for Web Revised Jan
2013 v0 4 8 22 January 2013 Author D J Tudor
33. What is meant by “Yesterday’s Weather” in an Agile project?
A. Teams work less well when it rains
B. Keeping metrics of earlier work to help with future estimates
C. Retrospectives should include less important topics, such as the weather, as ice-breakers
D. Estimating is as futile as predicting the weather
34. In Agile projects, we plan to “learn as we go” because…
A. It creates a better relationship between the developers and customer representatives
B. Many projects are evolutionary, and a better solution emerges this way
C. It is time-consuming to analyse everything at the beginning of a project
D. It prevents late delivery of the project
35. The recommended approach to design in an Agile project is:
A. No design up front
B. Big design up front
C. Just enough design up front
D. Use a previous design – it will be “good enough”
36. What is the personal risk that an Agile Leader takes in empowering the team?
A. The Agile Leader might lose their job, as the team is doing all the work
B. If the team fails, the Agile leader will not get a performance bonus
C. The Agile Leader has less direct control over the team’s work, but still has the responsibility
for their outcomes
D. The Agile Leader cannot share the glory of team success
37. The Agile approach to documentation is:
A. Do no documentation because it is a waste of time
B. Do sufficient documentation to prove you have done a good job
C. Do the necessary documentation to support the development and use of the product
D. Do more documentation than usual, because Agile is risky
38. The Agile way is:
A. To produce working product of the right quality, early and incrementally
B. To produce working product after documentation has been signed off
C. To produce simple prototypes early, but no finished product until the end of the project
D. To produce products without technical integrity, but re-engineer later Sample Questions with
Answers for Web Revised Jan 2013 v0 4 9 22 January 2013 Author D J Tudor
39. The customer in an Agile project ….
A. Has no control over the prioritization of delivered features
B. Has total control over the prioritization of features
C. Collaborates with the developers over prioritization of features, but the developers have the
final decision
D. Collaborates with the developers over prioritization of features, but the business has the
final decision
40. In the popular prioritization technique called “MoSCoW”, the “M” stands for ...
A. May have
B. Major
C. Must Have
D. Mandatory
41. The working culture of an Agile team is …
A. Collective
B. Collaborative
C. Connective
D. Contemplative
42. The leadership style of an Agile Leader is …
A. Directive
B. Assertive
C. Facilitative
D. Feature-based
43. The Agile Manifesto states the following values:
A. People are more important than contracts
B. Working software should have priority over comprehensive documentation
C. Plans should have priority over ability to respond
D. Contracts should be negotiated which allow control over the people
44. Which of the following are attributes of an Agile team?
A. Courage to change and adapt
B. Trust of fellow team members to do the work
C. Responsiveness to change
D. All of these Sample Questions with Answers for Web Revised Jan 2013 v0 4 10 22 January 2013 Author D J Tudor
45. A sustainable pace means …
A. If the team members work long hours regularly they will get used to it, and be able to sustain
it
B. A 40 hour week is only for the weaker members of the team. Others can do more.
C. The team should establish a velocity which can be sustained within normal working hours
D. Working long hours is the only way to deliver on time
46. A burn-down chart shows …
A. The energy level and velocity of the team
B. The remaining work (effort, points) to complete before the iteration (timebox) end
C. The number of hours worked by each team member during the iteration (timebox)
D. The rate of spending of the budget for a project
47. The reason for holding regular Retrospectives is:
A. It allows the team to take a necessary break from work
B. It gives management information to use in team members’ performance reviews
C. It allows learning which can be used to improve team performance during the project
D. It prevents deviation from the process which the team has been following
48. Once a project is underway, the approach to planning is:
A. Plans should never be changed
B. It is normal to need to plan and re-plan as the project progresses
C. Plans should only be changed with full approval of all stakeholders
D. Plans are not required as Agile is incremental
49. An Agile project …
A. Should have no control over its progress
B. Should be able to demonstrate control of its progress
C. Is always out of control
D. Is controlled by the velocity of the most junior team member
50. An Agile project should have ...
A. Occasional early deliveries, if the business is prepared to accept lower quality
B. A regular pattern of delivery of developer-focused products
C. A regular pattern of delivery of business-valued increments
D. An irregular and unpredictable delivery of products Sample Questions with Answers for Web Revised Jan
2013 v0 4 11 22 January 2013 Author D J Tudor
51. When an Agile team is successful …
A. It should be encouraged to celebrate success only when the project is over
B. It should be encouraged to celebrate even small successes immediately
C. It should not celebrate success, as this wastes project budget
D. It should not celebrate success, as this makes less successful teams feel bad
52. In order to communicate well, the Agile project should ...
A. Keep team-size large, to avoid stakeholders feeling left out
B. Break the project into small, mixed-skill, self-organising teams
C. Operate with one team of less than 10 people
D. Operate with separate customer, developer and test teams
53. If a new requirement emerges once an Agile project is running, it should be:
A. Automatically included in the work of the project
B. Automatically excluded and left until a later project or increment
C. Assessed for importance and, if sufficiently important to the business, included in the
project, displacing less important requirements
D. Put on the backlog for consideration by the wider group of stakeholders after the project has
been completed
54 . You have been engaged as the Technical Coordinator in a product development team. The
customer (Product Owner) and Team Leader (Scrum Master) are happy because the team always
delivers business value on time. However, you worry that the technical debt is increasing. What
would be your primary goal to ensure the right quality?
A. Ensure testers define their entry criteria for quality, which they impose on the development
team
B. Nothing. Prescribed roles such as technical coordinators are not part of an Agile team
C. Make sure that the maintainability quality attribute is addressed
D. On time delivery and happy end users are the only quality measures in Agile development
55. How could maintainability of the developing product be improved in a development team?
A. Apply standard design patterns
B. All of these
C. Make refactoring a common practice
D. Ensure unit testing is included in the “done” criteria
Sample Questions with Answers for Web Revised Jan 2013 v0 4 12 22 January 2013 Author D J Tudor
56. Agile methods are described as “adaptive” because…
A. Agile teams have the empowerment to frequently respond to change and to learn on a
project by changing the plan
B. The rate of development progress on an Agile project is constantly tracked to allow
adaptation
C. Project Managers are not needed in Agile methods because teams are self-organising
D. Workshops held at the beginning and the end of every iteration (timebox) allow the team to
adapt the product specification
57. What do all Agile approaches have in common?
A. A prescribed, fixed iteration (timebox) length
B. Iterative development and incremental delivery
C. A strict focus on on-time delivery
D. A large set of clearly defined roles
58. What is one difference in responsibility between a Project Manager and a Scrum Master
(Team Leader) in an Agile project?
A. None. It's basically the same. Scrum Master (or Team Leader) is just a better term than
Project Manager in an Agile project
B. The Project Manager creates the detailed delivery plans while the Team Leader monitors
execution within the team
C. Project Manager communicates with project governance authorities when necessary
D. The Project Manager monitors the realisation of benefits in the business case.
59. How could you benefit from having an End User Representative in your development team?
A. End users should NOT be in the development team. Requirements are always communicated
to the developers by the Product Owner, who is part of the customer team
B. The End User Representative will be solely responsible for acceptance tests within the team
C. The End User Representative assures that user stories are documented properly
D. The End User Representative will be able to clearly tell the developers what will work for
an end user
60. The responsibilities of a Product Owner will include …
A. Business processes diagramming
B. Prioritizing requirements
C. Managing the project budget
D. All of these

How to Choose Quality Candidates/Consultants for Your Large Company Agile

Initiative

Daryl Kulak & Anita Shankar, http://www.perficient.com/

We created this set of questions to help corporate managers select Agile-

experienced consultants and candidate employees for project work.
Assembling a team of qualified Agile people is one thing, but the fact that
some Agile practices and principles mean different things to different
people makes it even harder to succeed in staffing your initiatives.

A consultant or potential employee who has great Agile experience in

small product companies may be exactly the wrong type of person to help
you inside a large corporation. An Agile evangelist from a small product
company may actually be horrified by some of the compromises that are
absolutely necessary in your large company environment. We developed
this questionnaire to make those distinctions.

Depending on the role you are interviewing for, you may want to leave
certain questions out or perhaps add some of your own. Certainly there
will be questions you want to ask about things like the person’s outlook
towards businesspeople and technical people working closely together,
which is important no matter whether the project is waterfall or Agile.

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.

References:

Our work is based on the research paper by Dr. Hong Li. The paper is
available here:

http://agileplusrigor.ning.com/forum/topic/show?id=2075814%3ATopic%
3A565

Here is some good reading on Agile in the enterprise:

Augustine, S. - Managing Agile Projects (Prentice Hall PTR, 2005), 264p

Highsmith, J. – Agile Project Management (Addison-Wesley, 2004), 312p

Leffingwell, D. – Scaling Software Agility (Addison-Wesley, 2007), 384p

Possible related articles and blogs of interest:

LitheSpeed Blog: lithespeed.blogspot.com

The Agile Executive: trailridgeconsulting.com/blog

Leading Answers: leadinganswers.typepad.com

Scaling Software Agility: scalingsoftwareagility.wordpress.com

Related Agile Articles

Adopting an Agile Method

Creating an Agile Environment

Five Symptoms of Mechanical Agile

More Agile Knowledge

 Scrum Expert

Agile Tutorials and Videos

Agile Software Development

Related Agile and Scrum Books

Coaching Agile Teams

Succeeding with Agile

http://atozmcqs.blogspot.in/2014/01/105-top-agile-testing-multiple-choice.html

************************************************************************

Kanban
Kanban is a lean approach to agile software development.

Actually, Kanban means many things. Literally, Kanban is a Japanese word that means “visual
card”. At Toyota, Kanban is the term used for the visual & physical signalling system that ties
together the whole Lean Production system. Most agile methods such as Scrum and XP are
already well aligned with lean principles. In 2004, however, David Anderson pioneered a more
direct implementation of Lean Thinking and Theory of Constraints to software development.
Under the guidance of experts such as Don Reinertsen, this evolved into what David called a
“Kanban system for software development”, and which most people now simply refer to as
“Kanban”. So while Kanban as applied to software development is new, Kanban as used in Lean
Production is over a half century old.

Does Kanban matter to me?

Do any of these sound familiar?

o “We’ve done Scrum for a long time now and our process improvement has levelled off. How can
we take our process to the next level?”
o “Our needs and priorities shift on a daily basis”
o “We don’t like fixed-length, fixed-commitment iterations”
o “We are spending too much time planning and estimating”
If so, read on. Along with Scrum and XP, Kanban should be part of the process toolkit of any
agile company. The choice of where & when to use it can only be made by you though.
 How does Kanban work?
There are many flavors, but the core of Kanban means:

1. Visualize the workflow

o Split the work into pieces, write each item on a card and put on the wall.
o Use named columns to illustrate where each item is in the workflow.
2. Limit WIP (work in progress) – assign explicit limits to how many items may be in progress
at each workflow state.
3. Measure the lead time (average time to complete one item, sometimes called “cycle time”),
optimize the process to make lead time as small and predictable as possible.
This is a direct implementation of a lean pull scheduling system. Here’s an example of a simple
Kanban board, with WIP limits in red.

Here’s a more complex one (see Kanban kick-start example for a closer look & description)

What are the benefits of Kanban?

Some commonly observed benefits are:

o Bottlenecks become clearly visible in real-time. This leads people to collaborate to optimize the
whole value chain rather than just their part.
o Provides a more gradual evolution path from waterfall to agile software development, thereby
helping companies that previously have been unable or unwilling to try agile methods.
o Provides a way to do agile software development without necessarily having to use time-boxed
fixed-commitment iterations such as Scrum sprints. Useful for situations where sprints don’t
make much sense, such as operations and support teams with a high rate of uncertainty and
variabilty.
o Tends to naturally spread throughout the organization to other departments such as HR and
sales, thereby increasing visibility of everything that is going on at the company.

Can I combine Kanban with my

current process?
Yes. In fact, you should combine it. In Kanban the first step is to visualize your current process,
just as it is, in order to see where the bottlenecks are. Then you introduce WIP limits and start a
path of evolution that may or may not modify or replace your current process over time. See
“Kanban & Scrum – making the most of both”, where Henrik Kniberg and Mattias Skarin illustrate
how Kanban and Scrum relate to each other.

Where is Kanban used?

Our coaches at Crisp have helped several clients use Kanban to improve their process. In fact, a
surprising number of our clients have found that Kanban is an extremely useful complement (or
sometimes even a replacement) to other popular agile methods such as Scrum. Typical manager
comment: “It really helps us visualize our projects and situation”. There is also an increasing
number of case studies available atwww.limitedwipsociety.org. Here are a few examples:
o Improving operations using Kanban, Mattias Skarin, Developerdays 2009
o David Anderson’s case study – and why lead time is best metric
o David Joyce shows how a Scrum team improves by moving to Kanban with Statistical process
control data

Common misunderstandings about

Kanban
o Myth: With Kanban you don’t use iterations
o Fact: With Kanban iterations are optional. Do it only if you have a need for it in your context.
o Myth: With Kanban you don’t estimate
o Fact: With Kanban estimation is optional. Do it only if you have a need for it in your context.
o Myth: Kanban is better than Scrum/XP/RUP/whatever
o Fact: Kanban is just a process tool, and there is no such thing as a universally good or bad tool.
It all depends on your context. See this article for more info.
o Myth: Kanban is a drop-in replacement to Scrum/XP/RUP/whatever
o Fact: Kanban is just about managing workflow. It hardly replaces anything. What it does do,
however, is drive change. In Kanban you start with whatever process you have, visualize it,
introduce WIP limits, and then evolve from there.
 Case examples
Marketing

o Kanban in inbound marketing

o Bringing kanban into marketing
Enterprise

o Enterprise Kanban (article by Mattias) - shows how Kanban can be used to improve the full
value stream
Multi team projects

o Lean from the Trenches – Managing Large Scale Projects with Kanban (book by Henrik) – shows
advanced application of Kanban in a 60-person project
Operations

o Kanban & Scrum, making the most of both (book by Henrik & Mattias)

Further reading
o Kanban (book by David J Anderson)
o Kanban & Scrum, making the most of both (book by Henrik & Mattias)
o 10 kanban boards and their context (article by Mattias)
o Converting a Scrum team to Kanban (article by Mattias)
o www.limitedwipsociety.org – main Kanban resource site
o One day in Kanban land (comic strip by Henrik)
o Kanban kick-start example (template by Henrik)
o How can support and operations be Agile (slides by Mattias)
o Mattias’ blog entries on Kanban and more
o Henrik’s blog entries on Kanban and more
o Queue utilization is a leading indicator (Corey Ladas)

Scrum
Scrum and Kanban are both empirical in the sense that you are expected to experiment with the process
and customize it to your environment. In fact, you have to experiment. Neither Scrum nor Kanban provide
all the answers – they just give you a basic set of constraints to drive your own process improvement.

Scrum Summary
Scrum is an iterative, incremental framework for projects and product or application development. It
structures development in cycles of work called Sprints. These iterations are no more than one month
each, and take place one after the other without pause. The Sprints are timeboxed – they end on a
specific date whether the work has been completed or not, and are never extended. At the beginning of
each Sprint, a cross-functional team selects items 5 (customer requirements) from a prioritized list. The
team commits to complete the items by the end of the Sprint. During the Sprint, the chosen items do not
change. Every day the team gathers briefly to inspect its progress, and adjust the next steps needed to
complete the work remaining. At the end of the Sprint, the team reviews the Sprint with stakeholders,
and demonstrates what it has built. People obtain feedback that can be incorporated in the next Sprint.
Scrum emphasizes working product at the end of the Sprint that is really “done”; in the case of software,
this means code that is integrated, fully tested and potentially shippable.
A major theme in Scrum is “inspect and adapt.” Since development inevitably involves
learning, innovation, and surprises, Scrum emphasizes taking a short step of development,
inspecting both the resulting product and the efficacy of current practices, and then adapting
the product goals and process practices. Repeat forever.

Like any tools, Scrum and Kanban are neither perfect nor complete. They don’t tell you everything
that you need to do, they just provide certain constraints & guidelines

S.No Scrum Kanban

1. It constrains you to have
timeboxed iterations and cross-functional
teams
2. Scrum prescribes 3 roles:
 Product Owner (sets product vision
&priorities)
 Team (implements the product)
 Scrum Master (removes impediments
and provides process leadership)
3. It limits WIP per iteration
It constrains
you to use visible boards and limit the size of
your queues i.e. limit WIP(Work-in-progress)
Kanban doesn’t prescribe any roles at all.
That doesn’t mean you can’t or shouldn’t have a
Product Owner role in
Kanban! It just means you don’t have to. In both
Scrum and Kanban you
are free to add whatever additional roles you
need.
It limits WIP per workflow state

Points to be noted:

1. Process = how you work.

Tool = anything used as a means of accomplishing a task or purpose.

Scrum and Kanban are process tools in that they help you work more effectively by, to a certain extent,
telling you what to do. Which tool is better depends upon your context. For a given situation, a particular
tool is better

2. No tool is complete and no tool is perfect. Like any tools, Scrum and Kanban are
neither perfect nor complete. They don’t tell you everything that you need to do, they just
provide certain constraints & guidelines. For example, Scrum constrains you to have
timeboxed iterations and cross-functional teams, and Kanban constrains you to use visible
boards and limit the size of your queues.

3. Interestingly enough, the value of a tool is that it limits your options. A process tool that
lets you do anything is not very useful. We might call that process “Do Whatever” or how
about “Do The Right Thing”

4. Using the right tools will help you succeed, but will not guarantee success. It's easy to confuse
project success/failure with tool success/failure.
A project may succeed because of a great tool.
A project may succeed despite a lousy tool.
A project may fail because of a lousy tool.
 A project may fail despite a great tool..

5. Prescriptive means “more rules to follow” and adaptive means “fewer rules to follow”.
100% prescriptive means you don’t get to use your brain, there is a rule for everything.
100% adaptive means Do Whatever, there are no rules or constraints at all.

6. Agile methods are sometimes called lightweight methods, specifically because they are
less prescriptive than traditional methods. Scrum and Kanban are both highly adaptive,
but relatively speaking, Scrum is more prescriptive than Kanban. Scrum gives you more
constraints, and thereby leaves fewer options open. For example Scrum prescribes the use
of timeboxed iterations, Kanban doesn’t

7. XP (eXtreme Programming) is pretty prescriptive compared to Scrum. It includes most of

Scrum + a bunch of fairly specific engineering practices such as test-driven development
and pair programming

8. One of the main differences between Scrum and RUP is that in RUP you get too much, and you
are supposed to remove the stuff you don’t need. In Scrum you get too little, and you are supposed
to add the stuff that is missing. Kanban leaves almost everything open. The only constraints are
Visualize Your Workflow and Limit Your WIP. Just inches from Do Whatever, but still
surprisingly powerful.

9. Don’t limit yourself to one tool. Mix and match the tools as you need! I can hardly imagine a
successful Scrum team that doesn’t include most elements of XP for example. Many Kanban
teams use daily standup meetings (a Scrum practice). Some Scrum teams write some of their
backlog items as Use Cases (a RUP practice) or limit their queue sizes (a Kanban practice).
Whatever works for you.

10. The general mindset in both Scrum and Kanban is “less is more”. So when in doubt, start
with less.