Agile Methodology

Section A

Unit 1

1. Write the values of agile manifesto and principles

2. Explain importance of pair programming in agile
3. Explain the impact of agile life cycle on agile testing
4. Why agile methodology is more effective than waterfall model
5. Explain how XP team makes its design simple and expressive
6. Explain lean software development. How we can use lean principles for better
project management
7. What is FDD? Explain the process of FDD with neat labelled diagram
8. What is agile development model? Explain the different methodologies in agile
software development
9. Explain XP
10. Explain agile testing quadrant with suitable diagram
11. Differentiate between waterfall model and agile
12. Differentiate between XP and FDD

Unit 2

1. Explain SCRUM with neat labelled diagram

2. Explain the characteristics of SCRUM team
3. Daily SCRUM
4. Burn down chart
5. Project velocity
6. User stories
7. SCRUM is instrumental and interactive justify this statement
8. What is sprint and how the velocity of sprint measured
9. Explain the characteristics of good user stories
10. How agile estimation and planning is done? Explain planning poker
11. Explain following meeting of SCRUM
i. Sprint planning
ii. Sprint review
iii. Sprint retrospective
iv. Daily scrum
12. Story point
13. Epic user story
14. Spike
15. Product owner
16. Scrum master
17. Define product backlog? Why product backlog grooming and refinement is
necessary
 18. Explain product backlog and sprint backlog

Unit 3

1. Explain relationship between refactoring and test driven development

2. Risk based testing
3. Explain exploratory testing
4. Explain refactoring with suitable example
5. X unit framework
6. Explain the importance of regression testing in agile
7. What is TDD? Explain its steps with suitable diagram
8. What is acceptance test? Explain any one tool to support agile tester

Section B

Unit 4

1. What are the SOLID principles? Explain OCP with suitable example
2. What is the role of design principles in agile? Explain with open closed principle
3. Explain single responsibility design principles
4. Explain the symptoms of bad software design write the statement of single
responsibility and interface segregation principle
5. Explain interface segregation principle
6. Explain Liskov substitution design principle with suitable example
7. Explain why agile design practices important

Unit 5

1. Explain dependency inversion principle with suitable examples

2. Explain process of continuous integration with suitable diagram
3. What is version control? Explain its significance in agile software development.
Explain remote and distributed version control system
4. Explain relation between continuous integration and version control

Unit 6

1. How agility is balanced with discipline

2. Explain the need and significance of refactoring
3. Explain refactoring and any 5 refactoring techniques
4. Explain any automated build tool
5. Explain the issues while adopting agile in industry & What are business benefits
of agile methodology
6. What is meant by agile distributed team? Explain the roles in an agile project
7. Write a note on agile projects on cloud
8. Explain how agile and cloud computing practices complement each other
9. Explain the challenges in agile
10. Write a note on agile ALM
 11. Explain why agile can work well unit distributed teams OR Explain role of agile in
distributed team
12. What are the practical challenges which constraints the use of agile methodology
13. How can cloud computing enhance agile software development
14. Justify how agile in distributed teams can prove more successful than current
software development methodology
15. Explain different roles in agile project

Section A

Unit 1

1. Write the values of agile manifesto and principles

2. “Agile” as the term was applied to this set of methodologies in 2001.

3. It was the collaboration of 17 software developers who gathered in Utah, USA, to

discuss their ideas and different approaches to software development. Their smart
thoughts were expressed in the famous Agile Manifesto that included 12 principles.

4. The Agile Manifesto consists of 4 foundational values and 12 supporting principles

that lead the Agile approach to software development.

5. Each Agile methodology applies the 4 values in different ways. However, all of them
rely on these values to guide the development and delivery of high-quality, working
software.
4 values of the Agile Manifesto

1. Individuals and interactions over processes and tools

The value #1 in the Agile Manifesto is known as “Individuals and interactions over processes and
tools.” It’s crucial to value people more highly than processes or tools. It is the people who
respond to business needs and drive the development process. When the development is driven
by the process or tools, then the team is less responsive to changes and less likely to meet
customer needs.

2. Software over documentation

Historically, documenting the product for development and ultimate delivery required enormous
amounts of time. Technical requirements, specifications, prospectus, testing plans, interface
design documents, and different approvals were required for each. There were long delays in
development.
Agile streamlines documentation, not eliminating it. In this form, it gives developers what they
need to do without getting bogged down in minutiae. Agile values documentation, but it values
working software more.

3. Customer collaboration over contract negotiation

Negotiations are important. It’s about the period when customers and a product manager work
out the details of a delivery with all the details. However, collaboration is a different creature
entirely and it really matters.

According to Waterfall, customers negotiate the requirements for the product, often in great
detail, prior to any work starting. The Agile Manifesto describes a customer who collaborates
throughout the development process, making. It’s easier for development to meet their needs of
the customer.

According to Agile methods, the customer may be included at intervals for periodic demos, but a
project could just as easily have an end-user as a daily part of the team.

4. Responding to changes over following a plan

Traditional software development regarded change as an expense. It was to be avoided.

According to Agile, the shortness of an iteration means priorities can be shifted from iteration to
iteration and new features can be added into the next iteration. Changes always improve a
project and provide additional value.

12 principles of Agile development

These principles can be your litmus test to define whether or not you’re being Agile. So, always
remember them in a short form:

1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change
for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
 6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity — the art of maximizing the amount of work not done — is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.

6. Explain importance of pair programming in agile

Pair programming is what it sounds like: programming in pairs. Two programmers work together
at the same computer on a single task. The “pair programmers” switch between two roles:
the driver and the navigator (or observer).

The driver controls the keyboard and mouse. They are responsible for writing the code. The
driver’s focus is usually on a single section of code, and the mechanics of modifying that code.

The navigator oversees the code entered by the driver, and is responsible for making sure the
pair is not only working, but doing the right work. The driver is focused on the current task, and
the navigator is more of a visionary. They will be thinking a step or two ahead, while maintaining
an open dialog with the driver.

The driver and the navigator should have a constant back-and-forth. An effective pair
communicates fluidly, mutually motivated to find the best solution to the problem at hand.

Benefits

 increased code quality: "programming out loud" leads to clearer articulation of the complexities
and hidden details in coding tasks, reducing the risk of error or going down blind alleys
 better diffusion of knowledge among the team, in particular when a developer unfamiliar with a
component is pairing with one who knows it much better
 better transfer of skills, as junior developers pick up micro-techniques or broader skills from more
experienced team members
 large reduction in coordination efforts, since there are N/2 pairs to coordinate instead of N
individual developers
 improved resiliency of a pair to interruptions, compared to an individual developer: when one
member of the pair must attend to an external prompt, the other can remains focused on the task
and can assist in regaining focus afterwards

Pair Programming Advantages

There are several compelling reasons you should consider this strategy:

 Two heads are better than one. If the driver encounters a hitch with the code, there will be
two of them who’ll solve the problem.
 More efficient. Common thinking is that it slows down the project completion time
because you are effectively putting two programmers to develop a single program, instead
of having them work independently on two different programs. But studies have shown
that two programmers working on the same program are only 15% slower than when these
programmers work independently, rather than the presupposed 50% slow down.
 Fewer coding mistakes. Because there is another programmer looking over your work, it
results in better code. In fact, an earlier study shows that it results in 15% fewer bugs than
code written by solo programmers. Plus, it allows the driver to remain focus on the code
being written while the other attends to external matters or interruption.
 An effective way to share knowledge. Code Fellows talks about how it could help
programmers learn from their peers in this blog post. It would allow programmers to get
instant face-to-face instruction, which is much better than online tutorials and faster than
looking for resources on the Internet. Plus, you can learn things better from your partner,
especially in areas that may be unfamiliar to you. Developers can also pick up best practices
and better techniques from more advanced programmers. It can also facilitate mentoring
relationships between two programmers.
 Develops your staff’s interpersonal skills. Collaborating on a single project helps your team
to appreciate the value of communication and teamwork.

In sum, it helps your programmers learn from each other while coming up with programs and
applications with better code quality and fewer bugs.

Alistair Cockburn of Humans and Technology and Laurie Williams of the University of Utah –
Computer Science Department have come up with a bullet list of benefits:

 Fewer mistakes are introduced into your code because a lot of errors are caught as they are
being typed. This level of continuous code reviews gives rise to fewer bugs in your code.
 You have shorter and tighter code.
 Two people can solve the problems that crop up along the way faster and quicker.
 Your developers learn more about things that are specific to the applications that they are
working on as well as software development in general, best practices, and other areas.
 You have more people who know how the new program works. This means that if one of
the pair leaves the company, it will not kill the project.
 Your team develops better interpersonal and social skills. Team members can learn to
communicate with each other, work together, and share information.
 Your team members are more satisfied.

7. Explain the impact of agile life cycle on agile testing

8. Why agile methodology is more effective than waterfall model

What is Waterfall methodology?

Waterfall Model methodology which is also known as Liner Sequential Life Cycle Model.
Waterfall Model followed in the sequential order, and so project development team only
moves to next phase of development or testing if the previous step completed successfully.

What is the Agile methodology?

Agile methodology is a practice that helps continuous iteration of development and testing in
the software development process. In this model, development and testing activities are
concurrent, unlike the Waterfall model. This process allows more communication between
customers, developers, managers, and testers.

Advantages of Waterfall Model:

 It is one the easiest model to manage. Because of its nature, each phase has specific
deliverables and a review process.
 It works well for smaller size projects where requirements are easily understandable.
 Faster delivery of the project
 Process and results are well documented.
 Easily adaptable method for shifting teams
 This project management methodology is beneficial to manage dependencies.

Advantages of the Agile Model:

 It is focused client process. So, it makes sure that the client is continuously involved
during every stage.
 Agile teams are extremely motivated and self-organized so it likely to provide a better
result from the development projects.
 Agile software development method assures that quality of the development is
maintained
  The process is completely based on the incremental progress. Therefore, the client and
team know exactly what is complete and what is not. This reduces risk in the
development process.

Limitations of Waterfall Model:

 It is not an ideal model for a large size project

 If the requirement is not clear at the beginning, it is a less effective method.
 Very difficult to move back to makes changes in the previous phases.
 The testing process starts once development is over. Hence, it has high chances of bugs
to be found later in development where they are expensive to fix.

Limitations of Agile Model

 It is not useful method for small development projects.

 It requires an expert to take important decisions in the meeting.
 Cost of implementing an agile method is little more compared to other development
methodologies.
 The project can easily go off track if the project manager is not clear what outcome
he/she wants.

Difference between Agile and Waterfall Model:

Agile Waterfall

It separates the project development Software development process is divided into

lifecycle into sprints. distinct phases.

It follows an incremental approach Waterfall methodology is a sequential design

process.

Agile methodology is known for its Waterfall is a structured software

flexibility. development methodology so most times it
can be quite rigid.

Agile can be considered as a collection of Software development will be completed as

many different projects. one single project.

Agile is quite a flexible method which allows There is no scope of changing the
changes to be made in the project requirements once the project development
development requirements even if the starts.
initial planning has been completed.
Agile methodology, follow an iterative
development approach because of this
planning, development, prototyping and
other software development phases may
appear more than once.
Test plan is reviewed after each sprint
Agile development is a process in which the
requirements are expected to change and
evolve.
In Agile methodology, testing is performed
concurrently with software development.
Agile introduces a product mindset where
the software product satisfies needs of its
end customers and changes itself as per the
customer's demands.
Agile methdology works exceptionally well
with Time & Materials or non-fixed funding.
It may increase stress in fixed-price
scenarios.
Prefers small but dedicated teams with a
high degree of coordination and
synchronization.
Products owner with team prepares
requirements just about every day during a
project.
Test team can take part in the requirements It is difficult for the test to initiate any change
All the project development phases like
designing, development, testing, etc. are
completed once in the Waterfall model.
The test plan is rarely discussed during the
test phase.
The method is ideal for projects which have
definite requirements and changes not at all
expected.
In this methodology, the "Testing" phase
comes after the "Build" phase
This model shows a project mindset and
places its focus completely on accomplishing
the project.
Reduces risk in the firm fixed price contracts
by getting risk agreement at the beginning of
the process.
Team coordination/synchronization is very
limited.
Business analysis prepares requirements
before the beginning of the project.
change without problems. in requirements.

Description of project details can be altered Detail description needs to implement

anytime during the SDLC process. waterfall software development approach.

The Agile Team members are
interchangeable, as a result, they work
faster. There is also no need for project
managers because the projects are
managed by the entire team
In the waterfall method, the process is always
straightforward so, project manager plays an
essential role during every stage of SDLC.

Conclusion:

Agile and Waterfall are very different software development methodologies and are good in
their respective way.

However, there are certain major differences highlighted below -

 Waterfall model is ideal for projects which have defined requirements, and no changes
are expected. On the other hand, Agile is best suited where there is a higher chance of
frequent requirement changes.
 The waterfall is easy to manage, sequential, and rigid method.
 Agile is very flexible and it possible to make changes in any phase.
 In Agile process, requirements can change frequently. However, in a waterfall model, it
is defined only once by the business analyst.
 In Agile Description of project, details can be altered anytime during the SDLC process
which is not possible in Waterfall method.

9. Explain how XP team makes its design simple and expressive

10. Explain lean software development. How we can use lean principles for better
project management
Lean software development is a translation of lean manufacturing principles and practices to
the software development domain. Adapted from the Toyota Production System,[1] it is
emerging with the support of a pro-lean subculture within the Agile community. Lean offers a
solid conceptual framework, values and principles, as well as good practices, derived from
experience, that support agile organizations. Lean principles[edit]
Lean development can be summarized by seven principles, very close in concept to lean
manufacturing principles:[4]

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole
Eliminate waste[edit]
Lean philosophy regards everything not adding value to the customer as waste (muda). Such
waste may include:[5]

1. Partially done work

2. Extra processes
3. Extra features
4. Task switching
5. Waiting
6. Motion
7. Defects
8. Management activities
Industry research revealed these software development wastes:[6]

1. Building the wrong feature or product

2. Mismanaging the backlog
3. Rework
4. Unnecessarily complex solutions
5. Extraneous cognitive load
6. Psychological distress
7. Waiting/multitasking
8. Knowledge loss
9. Ineffective communication.
In order to eliminate waste, one should be able to recognize it. If some activity could be
bypassed or the result could be achieved without it, it is waste. Partially done coding eventually
abandoned during the development process is waste. Extra processes like paperwork and
features not often used by customers are waste. Switching people between tasks is waste.
Waiting for other activities, teams, processes is waste. Motion required to complete work is
waste. Defects and lower quality are waste. Managerial overhead not producing real value is
waste.
A value stream mapping technique is used to identify waste. The second step is to point out
sources of waste and to eliminate them. Waste-removal should take place iteratively until even
seemingly essential processes and procedures are liquidated.
Amplify learning
Software development is a continuous learning process based on iterations when writing code.
Software design is a problem solving process involving the developers writing the code and
what they have learned. Software value is measured in fitness for use and not in conformance
to requirements.
Instead of adding more documentation or detailed planning, different ideas could be tried by
writing code and building. The process of user requirements gathering could be simplified by
presenting screens to the end-users and getting their input. The accumulation of defects should
be prevented by running tests as soon as the code is written.
The learning process is sped up by usage of short iteration cycles – each one coupled with
refactoring and integration testing. Increasing feedback via short feedback sessions with
customers helps when determining the current phase of development and adjusting efforts for
future improvements. During those short sessions both customer representatives and the
development team learn more about the domain problem and figure out possible solutions for
further development. Thus the customers better understand their needs, based on the existing
result of development efforts, and the developers learn how to better satisfy those needs.
Another idea in the communication and learning process with a customer is set-based
development – this concentrates on communicating the constraints of the future solution and
not the possible solutions, thus promoting the birth of the solution via dialogue with the
customer.[jargon]
Decide as late as possible
As software development is always associated with some uncertainty, better results should be
achieved with a set-based or options-based approach, delaying decisions as much as possible
until they can be made based on facts and not on uncertain assumptions and predictions. The
more complex a system is, the more capacity for change should be built into it, thus enabling
the delay of important and crucial commitments. The iterative approach promotes this
principle – the ability to adapt to changes and correct mistakes, which might be very costly if
discovered after the release of the system.
With set-based development: If a new brake system is needed for a car, for example,
three teams may design solutions to the same problem. Each team learns about the
problem space and designs a potential solution. As a solution is deemed unreasonable,
it is cut. At the end of a period, the surviving designs are compared and one is chosen,
 perhaps with some modifications based on learning from the others - a great example of
deferring commitment until the last possible moment. Software decisions could also
benefit from this practice to minimize the risk brought on by big up-front design.
Additionally, there would then be multiple implementations that work correctly, yet are
different (implementation-wise, internally). These could be used to implement fault-
tolerant systems which check all inputs and outputs for correctness, across the multiple
implementations, simultaneously.
An agile software development approach can move the building of options earlier for
customers, thus delaying certain crucial decisions until customers have realized their needs
better. This also allows later adaptation to changes and the prevention of costly earlier
technology-bounded decisions. This does not mean that no planning should be involved –
on the contrary, planning activities should be concentrated on the different options and
adapting to the current situation, as well as clarifying confusing situations by establishing
patterns for rapid action. Evaluating different options is effective as soon as it is realized
that they are not free, but provide the needed flexibility for late decision making.
Deliver as fast as possible
In the era of rapid technology evolution, it is not the biggest that survives, but the fastest.
The sooner the end product is delivered without major defects, the sooner feedback can be
received, and incorporated into the next iteration. The shorter the iterations, the better the
learning and communication within the team. With speed, decisions can be delayed. Speed
assures the fulfilling of the customer's present needs and not what they required yesterday.
This gives them the opportunity to delay making up their minds about what they really
require until they gain better knowledge. Customers value rapid delivery of
a quality product.
The just-in-time production ideology could be applied to software development,
recognizing its specific requirements and environment. This is achieved by presenting the
needed result and letting the team organize itself and divide the tasks for accomplishing the
needed result for a specific iteration. At the beginning, the customer provides the needed
input. This could be simply presented in small cards or stories – the developers estimate the
time needed for the implementation of each card. Thus the work organization changes
into self-pulling system – each morning during a stand-up meeting, each member of the
team reviews what has been done yesterday, what is to be done today and tomorrow, and
prompts for any inputs needed from colleagues or the customer. This requires transparency
of the process, which is also beneficial for team communication.
Empower the team
There has been a traditional belief in most businesses about the decision-making in the
organization – the managers tell the workers how to do their own job. In a "Work-Out
technique", the roles are turned – the managers are taught how to listen to the developers,
so they can explain better what actions might be taken, as well as provide suggestions for
improvements. The lean approach follows the Agile Principle[7] "find good people and let
them do their own job,"[8] encouraging progress, catching errors, and removing
impediments, but not micro-managing.
Another mistaken belief has been the consideration of people as resources. People might
be resources from the point of view of a statistical data sheet, but in software
development, as well as any organizational business, people do need something more than
just the list of tasks and the assurance that they will not be disturbed during the completion
of the tasks. People need motivation and a higher purpose to work for – purpose within the
reachable reality, with the assurance that the team might choose its own commitments.
The developers should be given access to the customer; the team leader should provide
support and help in difficult situations, as well as ensure that scepticism does not ruin the
team’s spirit.
Build integrity in
The customer needs to have an overall experience of the System. This is the so-called
perceived integrity: how it is being advertised, delivered, deployed, accessed, how intuitive
its use is, its price and how well it solves problems.
Conceptual integrity means that the system’s separate components work well together as a
whole with balance between flexibility, maintainability, efficiency, and responsiveness. This
could be achieved by understanding the problem domain and solving it at the same time,
not sequentially. The needed information is received in small batch pieces – not in one vast
chunk - preferably by face-to-face communication and not any written documentation. The
information flow should be constant in both directions – from customer to developers and
back, thus avoiding the large stressful amount of information after long development in
isolation.
One of the healthy ways towards integral architecture is refactoring. As more features are
added to the original code base, the harder it becomes to add further improvements.
Refactoring is about keeping simplicity, clarity, minimum number of features in the code.
Repetitions in the code are signs of bad code designs and should be avoided. The complete
and automated building process should be accompanied by a complete and automated
suite of developer and customer tests, having the same versioning, synchronization and
semantics as the current state of the System. At the end the integrity should be verified
with thorough testing, thus ensuring the System does what the customer expects it to.
Automated tests are also considered part of the production process, and therefore if they
do not add value they should be considered waste. Automated testing should not be a goal,
but rather a means to an end, specifically the reduction of defects.
See the whole
Software systems nowadays are not simply the sum of their parts, but also the product of
their interactions. Defects in software tend to accumulate during the development process
– by decomposing the big tasks into smaller tasks, and by standardizing different stages of
development, the root causes of defects should be found and eliminated. The larger the
system, the more organizations that are involved in its development and the more parts are
developed by different teams, the greater the importance of having well defined
 relationships between different vendors, in order to produce a system with smoothly
interacting components. During a longer period of development, a stronger subcontractor
network is far more beneficial than short-term profit optimizing, which does not enable
win-win relationships.
Lean thinking has to be understood well by all members of a project, before implementing
in a concrete, real-life situation. "Think big, act small, fail fast; learn rapidly"[9] – these
slogans summarize the importance of understanding the field and the suitability of
implementing lean principles along the whole software development process. Only when all
of the lean principles are implemented together, combined with strong "common sense"
with respect to the working environment, is there a basis for success in software
development.

11. What is FDD? Explain the process of FDD with neat labelled diagram

Feature-Driven Development (FDD) is a client-centric, architecture-centric, and pragmatic

software process. The term "client" in FDD is used to represent what Agile Modeling (AM)
refers to as project stakeholders or eXtreme Programming (XP) calls customers. FDD was first
introduced to the world in 1999 via the book Java Modeling In Color with UML, a combination
of the software process followed by Jeff DeLuca's company and Peter Coad's concept of
features. FDD was first applied on a 15 month, 50-person project for a large Singapore bank in
1997, which was immediately followed by a second, 18-month long 250-person project. A more
substantial description is published in the book A Practical Guide to Feature-Driven
Development as well as the Feature Driven Development web site.

As the name implies, features are an important aspect of FDD. A feature is a small, client-valued
function expressed in the form <action><result><object>. For example, "Calculate the total of a
sale", "Validate the password of a user", and "Authorize the sales transaction of a customer".
Features are to FDD as use cases are to the Rational Unified Process (RUP) and user stories are
to Scrum - they're a primary source of requirements and the primary input into your planning
efforts.

As you see in Figure 1 there are five main activities in FDD that are performed iteratively. The
first is Develop An Overall Model, the initial result being a high-level object model and notes. At
the start of a project your goal is to identify and understand the fundamentals of the domain
that your system is addressing, and throughout the project you will flesh this model out to
reflect what you're building. The second step is Build A Features List, grouping them
into related sets and subject areas. These first two steps map to the initial envisioning effort of
AMDD (see Figure 2). Next you Plan By Feature, the end result being a development, the
identification of class owners (more on this in a minute), and the identification of feature set
owners. The majority of the effort on an FDD project, roughly 75%, is comprised of the fourth
and fifth steps: Design By Feature and Build By Feature. These two activities are exactly what
you'd expect, they include tasks such as detailed modeling, programming, testing, and
packaging of the system.

Figure 1. The FDD project lifecycle.

Figure 2. The lifecycle of AMDD.

An FDD project starts by performing the first three steps in the equivalent of the AD's Inception
phase or XP's "iteration 0", the goal being to identify the scope of the effort, the initial
architecture, and the initial high-level plan. Construction efforts occur in two-week (or less)
iterations, similar to XP or DAD teams, with the team iteratively working through all five steps
as needed. As with other agile software development processes, systems are delivered
incrementally by FDD teams.

There are six primary roles on an FDD project: Project Manager, Chief Architect, Development
Manager, Chief Programmer, Class Owner, and Domain Expert. An individual will take on one or
more roles on a project as you would expect. The concept of a class owner is where FDD differs
from XP. XP includes a practice called Collective Ownership the idea of which is that any
developer can update any artifact, including source code, as required. FDD takes a different
approach in that it assigns classes to individual developers, so if a feature requires changes to
several classes then the owners of those classes must work together as a feature team to
implement it. Just like programming pairs will model storm to think something through before
they code it, so will feature teams.

FDD also defines a collection of supporting roles, including:

 Domain Manager
 Release Manager
  Language Guru
 Build Engineer
 Toolsmith
 System Administrator
 Tester
 Deployer
 Technical Writer

FDD's five steps are supported by several practices. The first is domain object modeling, the
creation of a high-level class diagram and supporting artifacts that describes the problem
domain. Developing by feature and individual class ownership are also good practices, as is
having developers work together in feature teams. Inspections are an important aspect of FDD.
FDD also insists on regular builds, similar to XP, and configuration management. Finally, FDD
promotes a best practice called reporting/visibility of results, similar to XP and AM's philosophy
of open and honest communication.

How would Agile Modeling (AM) be applied on an FDD project? The principles and practices can
be clearly applied to FDD's two modeling-oriented steps - develop an overall model and design
by feature. The only apparent mismatch between the two processes is FDD's practice of class
ownership and AM's practice of collective ownership, but I would argue that this isn't the case.
FDD's practice pertains to coding but does not to modeling, on a FDD project people work
together in teams to model, along the lines of AM's model with others practice, and therefore
several people will be working on your shared collection of modeling artifacts.

12. What is agile development model? Explain the different methodologies in agile
software development

Agile development model is also a type of Incremental model. Software is developed in

incremental, rapid cycles. This results in small incremental releases with each release building
on previous functionality. Each release is thoroughly tested to ensure software quality is
maintained. It is used for time critical applications. Extreme Programming (XP) is currently one
of the most well known agile development life cycle model. Agile methodology is explained in
more detail under the Agile Tester topics. Diagram of Agile model:
Advantages of Agile model:

 Customer satisfaction by rapid, continuous delivery of useful software.

 People and interactions are emphasized rather than process and tools. Customers,
developers and testers constantly interact with each other.
 Working software is delivered frequently (weeks rather than months).
 Face-to-face conversation is the best form of communication.
 Close, daily cooperation between business people and developers.
 Continuous attention to technical excellence and good design.
 Regular adaptation to changing circumstances.
 Even late changes in requirements are welcomed

Disadvantages of Agile model:

 In case of some software deliverables, especially the large ones, it is difficult to assess
the effort required at the beginning of the software development life cycle.
 There is lack of emphasis on necessary designing and documentation.
 The project can easily get taken off track if the customer representative is not clear
what final outcome that they want.
 Only senior programmers are capable of taking the kind of decisions required during the
development process. Hence it has no place for newbie programmers, unless combined
with experienced resources.

When to use Agile model:

 When new changes are needed to be implemented. The freedom agile gives to change
is very important. New changes can be implemented at very little cost because of the
frequency of new increments that are produced.
 To implement a new feature the developers need to lose only the work of a few days, or
even only hours, to roll back and implement it.
 Unlike the waterfall model in agile model very limited planning is required to get
started with the project. Agile assumes that the end users’ needs are ever changing in a
 dynamic business and IT world. Changes can be discussed and features can be newly
effected or removed based on feedback. This effectively gives the customer the finished
system they want or need.
 Both system developers and stakeholders alike, find they also get more freedom of time
and options than if the software was developed in a more rigid sequential way. Having
options gives them the ability to leave important decisions until more or better data or
even entire hosting programs are available; meaning the project can continue to move
forward without fear of reaching a sudden standstill.

You can refer to our introduction to Agile Methodology if you would like to understand Agile
better however, the above information is sufficient for the ISTQB Foundation Level exam.

Other models you may want to study:

1. Waterfall model
2. V model
3. Incremental model
4. RAD model
5. Iterative model
6. Spiral model

Agile software development methods[edit]

Agile software development methods support a broad range of the software development life
cycle.[42] Some focus on the practices (e.g., XP, pragmatic programming, agile modeling), while
some focus on managing the flow of work (e.g., Scrum, Kanban). Some support activities for
requirements specification and development (e.g., FDD), while some seek to cover the full
development life cycle (e.g., DSDM, RUP).
Popular agile software development frameworks include (but are not limited to):

 Adaptive software development (ASD)

 Agile modeling
 Agile unified process (AUP)
 Disciplined agile delivery
 Dynamic systems development method (DSDM)
 Extreme programming (XP)
 Feature-driven development (FDD)
 Lean software development
 Kanban
 Rapid application development (RAD)
 Scrum
 Scrumban
 13. Explain XP

Extreme Programming − A way to handle the common shortcomings

Software Engineering involves −
 Creativity
 Learning and improving through trials and errors
 Iterations
Extreme Programming builds on these activities and coding. It is the detailed (not the only)
design activity with multiple tight feedback loops through effective implementation, testing
and refactoring continuously.
Extreme Programming is based on the following values −
 Communication
 Simplicity
 Feedback
 Courage
 Respect
What is Extreme Programming?
XP is a lightweight, efficient, low-risk, flexible, predictable, scientific, and fun way to develop a
software.
eXtreme Programming (XP) was conceived and developed to address the specific needs of
software development by small teams in the face of vague and changing requirements.
Extreme Programming is one of the Agile software development methodologies. It provides
values and principles to guide the team behavior. The team is expected to self-organize.
Extreme Programming provides specific core practices where −
 Each practice is simple and self-complete.
 Combination of practices produces more complex and emergent behavior.
Embrace Change
A key assumption of Extreme Programming is that the cost of changing a program can be held
mostly constant over time.
This can be achieved with −
 Emphasis on continuous feedback from the customer
 Short iterations
 Design and redesign
  Coding and testing frequently
 Eliminating defects early, thus reducing costs
 Keeping the customer involved throughout the development
 Delivering working product to the customer
Extreme Programming in a Nutshell
Extreme Programming involves −
 Writing unit tests before programming and keeping all of the tests running at all times.
The unit tests are automated and eliminates defects early, thus reducing the costs.
 Starting with a simple design just enough to code the features at hand and redesigning
when required.
 Programming in pairs (called pair programming), with two programmers at one screen,
taking turns to use the keyboard. While one of them is at the keyboard, the other
constantly reviews and provides inputs.
 Integrating and testing the whole system several times a day.
 Putting a minimal working system into the production quickly and upgrading it
whenever required.
 Keeping the customer involved all the time and obtaining constant feedback.
Iterating facilitates the accommodating changes as the software evolves with the changing
requirements.
Why is it called “Extreme?”
Extreme Programming takes the effective principles and practices to extreme levels.
 Code reviews are effective as the code is reviewed all the time.
 Testing is effective as there is continuous regression and testing.
 Design is effective as everybody needs to do refactoring daily.
 Integration testing is important as integrate and test several times a day.
 Short iterations are effective as the planning game for release planning and iteration
planning.

History of Extreme Programming

Kent Beck, Ward Cunningham and Ron Jeffries formulated extreme Programming in 1999. The
other contributors are Robert Martin and Martin Fowler.
In Mid-80s, Kent Beck and Ward Cunningham initiated Pair Programming at Tektronix. In the
80s and 90s, Smalltalk Culture produced Refactoring, Continuous Integration, constant testing,
and close customer involvement. This culture was later generalized to the other environments.
In the Early 90s, Core Values were developed within the Patterns Community, Hillside Group.
In 1995, Kent summarized these in Smalltalk Best Practices, and in 1996, Ward summarized it
in episodes.
In 1996, Kent added unit testing and metaphor at Hewitt. In 1996, Kent had taken the Chrysler
C3 project, to which Ron Jeffries was added as a coach. The practices were refined on C3 and
published on Wiki.
Scrum practices were incorporated and adapted as the planning game. In 1999, Kent published
his book, ‘Extreme Programming Explained’. In the same year, Fowler published his book,
Refactoring.
Extreme Programming has been evolving since then, and the evolution continues through
today.
Success in Industry
The success of projects, which follow Extreme Programming practices, is due to −
 Rapid development.
 Immediate responsiveness to the customer’s changing requirements.
 Focus on low defect rates.
 System returning constant and consistent value to the customer.
 High customer satisfaction.
 Reduced costs.
 Team cohesion and employee satisfaction.
Extreme Programming Advantages
Extreme Programming solves the following problems often faced in the software development
projects −
 Slipped schedules − and achievable development cycles ensure timely deliveries.
 Cancelled projects − Focus on continuous customer involvement ensures transparency
with the customer and immediate resolution of any issues.
 Costs incurred in changes − Extensive and ongoing testing makes sure the changes do
not break the existing functionality. A running working system always ensures sufficient
time for accommodating changes such that the current operations are not affected.
 Production and post-delivery defects: Emphasis is on − the unit tests to detect and fix
the defects early.
 Misunderstanding the business and/or domain − Making the customer a part of the
team ensures constant communication and clarifications.
 Business changes − Changes are considered to be inevitable and are accommodated at
any point of time.
 Staff turnover − Intensive team collaboration ensures enthusiasm and good will.
Cohesion of multi-disciplines fosters the team spirit.

14. Explain agile testing quadrant with suitable diagram

Combining the two aspects of Testing Types, the following Agile Testing Quadrants are derived
by Brian Marick −

The Agile Testing Quadrants provide a helpful taxonomy to help teams identify, plan and
execute the testing needed.
 Quadrant Q1 − Unit Level, Technology Facing, and supports the developers. Unit tests
belong to this Quadrant. These tests can be Automated tests.
 Quadrant Q2 − System level, business facing, and conform product behavior. Functional
tests belong to this quadrant. These tests are either manual or automated.
 Quadrant Q3 − System or User Acceptance Level, Business Facing and focus on real
time scenarios. User Acceptance Tests belong to this quadrant. These tests are manual.
 Quadrant Q4 − System or Operational Acceptance Level, Technology Facing and Focus
on Performance, Load, Stress, Maintainability, Scalability Tests. Special tools can be
used for these tests along with automation testing.
Combining these, the Agile Testing Quadrants that reflect What-Testing-When can be
visualized as follows −
Agile Quadrant I consists of test cases that are technology driven and are performed to
support the team
This quadrant focuses mainly on internal code quality. The unit testing done in this quadrant
acts as an initial safety net for the product and helps developer get the story right. By
performing the tests in Q1, instant feedback about the product can be obtained. When Test
Driven Development is adapted, design becomes better and stronger. The testability is
build into the code in this quadrant. Very few bugs will be found after coding is done. The kinds
of tests in this quadrant are –
1. Unit Tests including testing a piece of code and ensuring that it fulfills the requirements.

2. Component Tests including testing architect intent and ensuring that components work
together.

Agile Quadrant II consists of test cases that are business driven and are performed to support
the team
This quadrant focuses on eliciting the requirements. In this quadrant, developers can code as
long as the test cases give the expected results. The test cases are business facing and so
development is driven keeping the business objectives in mind. The objective of this quadrant is
to obtain enough requirements so that coding can commence without any hiccups. An
increased customer-tester-developer collaboration is possible in this quadrant. The kind of tests
in this quadrant are –

1. Testing of examples of possible scenarios and workflows.

2. Testing of User Experience such as prototypes.

3. Pair testing.

To experience Agile Quadrants in your Testing Cycles

 REQUEST A DEMO DOWNLOAD TRIAL

Agile Quadrant III consists of business facing test cases that critique the product
The main focus in this quadrant is to provide feedback to quadrants one and two. This quadrant
enables one to learn as test progresses. The test cases can be used as the basis to
perform automation testing. The product can be evaluated since realistic use of the product is
kept in mind in this quadrant. The process can be changed as needed. The many number of
iteration reviews in this quadrant builds confidence in the product and ensures the presence of
a quick feedback loop. The demo can be given even on unfinished code to gain insight into the
working of the product. Exploratory testing can be paired with the customer. The kind of tests
in this quadrant are -
1. Exploratory Testing

2. Usability Testing

3. Pair testing with customers

4. User Acceptance Testing

5. Collaborative Testing

Agile Quadrant IV consists of technology-driven test cases that critique the product
This quadrant focuses on the non-functional requirements such as performance, security,
stability etc. This quadrant is responsible to deliver the ultimately finished product. The
application is made to deliver the expected value and non-functional qualities with help of this
quadrant. Kind of tests in this quadrant -

1. Non-functional tests such as stress and performance testing

2. Security testing with respect to hacking and authentication.

3. Infrastructure testing.

4. Data migration testing.

5. Scalability testing

6. Load testing

15. Differentiate between waterfall model and agile

Agile Waterfall
It separates the project development
lifecycle into sprints.
It follows an incremental approach
Agile methodology is known for its
flexibility.
Agile can be considered as a collection of
many different projects.
Agile is quite a flexible method which allows There is no scope of changing the
changes to be made in the project
development requirements even if the
initial planning has been completed.
Agile methodology, follow an iterative
development approach because of this
planning, development, prototyping and
other software development phases may
appear more than once.
Test plan is reviewed after each sprint
Agile development is a process in which the
requirements are expected to change and
evolve.
In Agile methodology, testing is performed
concurrently with software development.
Agile introduces a product mindset where
the software product satisfies needs of its
end customers and changes itself as per the
Software development process is divided into
distinct phases.
Waterfall methodology is a sequential design
process.
Waterfall is a structured software
development methodology so most times it
can be quite rigid.
Software development will be completed as
one single project.
requirements once the project development
starts.
All the project development phases like
designing, development, testing, etc. are
completed once in the Waterfall model.
The test plan is rarely discussed during the
test phase.
The method is ideal for projects which have
definite requirements and changes not at all
expected.
In this methodology, the "Testing" phase
comes after the "Build" phase
This model shows a project mindset and
places its focus completely on accomplishing
the project.
customer's demands.
Agile methdology works exceptionally well
with Time & Materials or non-fixed funding.
It may increase stress in fixed-price
scenarios.
Prefers small but dedicated teams with a
high degree of coordination and
synchronization.
Products owner with team prepares
requirements just about every day during a
project.
Test team can take part in the requirements It is difficult for the test to initiate any change
change without problems.
Description of project details can be altered
anytime during the SDLC process.
The Agile Team members are
interchangeable, as a result, they work
faster. There is also no need for project
managers because the projects are
managed by the entire team
16. Differentiate between XP and FDD
Reduces risk in the firm fixed price contracts
by getting risk agreement at the beginning of
the process.
Team coordination/synchronization is very
limited.
Business analysis prepares requirements
before the beginning of the project.
in requirements.
Detail description needs to implement
waterfall software development approach.
In the waterfall method, the process is always
straightforward so, project manager plays an
essential role during every stage of SDLC.
Unit 2

1. Explain SCRUM with neat labelled diagram

Scrum is an agile process that allows us to focus on delivering the business value in the shortest
time. It rapidly and repeatedly inspects actual working software. It emphasizes accountability,
teamwork, and iterative progress toward a well-defined goal.

The Scrum Framework usually deals with the fact that the requirements are likely to change or
most of the time not known at the start of the project.

Scrum is an agile framework for managing knowledge work, with an emphasis on software
development, although it has wide application in other fields and is slowly starting to be
explored by traditional project teams more generally.[1] It is designed for teams of three to nine
members, who break their work into actions that can be completed within timeboxed
iterations, called sprints, no longer than one month and most commonly two weeks, then track
progress and re-plan in 15-minute time-boxed stand-up meetings, called daily scrums.[2][3]
Approaches to coordinating the work of multiple scrum teams in larger organizations
include large-scale scrum (LeSS), scaled agile framework (SAFe), scrum of scrums,
and Scrum@Scale, the Nexus, among others.
Scrum is a lightweight, iterative and incremental framework for managing product
development.[4][5] It defines "a flexible, holistic product development strategy where a
development team works as a unit to reach a common goal",[6] challenges assumptions of the
"traditional, sequential approach"[6] to product development, and enables teams to self-
organize by encouraging physical co-location or close online collaboration of all team members,
as well as daily face-to-face communication among all team members and disciplines involved.
A key principle of Scrum is the dual recognition that customers will change their minds about
what they want or need (often called requirements volatility[7]) and that there will be
unpredictable challenges—for which a predictive or planned approach is not suited. As such,
Scrum adopts an evidence-based empirical approach—accepting that the problem cannot be
fully understood or defined up front, and instead focusing on how to maximize the team's
ability to deliver quickly, to respond to emerging requirements, and to adapt to evolving
technologies and changes in market conditions.
There are three roles in the scrum framework. These are ideally co-located to ensure optimal
communication among team members. Together these three roles form the scrum team. While
many organizations have other roles involved with defining and delivering the product, Scrum
defines only these three.[16]
Scrum framework

Product owner[edit]
The product owner represents the product's stakeholders and the voice of the customer, is
responsible for the product backlog and accountable for maximizing the value that the team
delivers. The product owner defines the product in customer-centric terms (typically user
stories), adds them to the product backlog, and prioritizes them based on importance and
dependencies.[21] A scrum team should have only one product owner (although a product
owner could support more than one team).[22] This role should not be combined with that of
the scrum master. The product owner should focus on the business side of product
development and spend the majority of their time liaising with stakeholders and the engineers
which are part of their Team. The product owner should not dictate how the team reaches a
technical solution, but rather will seek consensus among the team
members.[23][better source needed] This role is crucial and requires a deep understanding of both sides:
the business and the engineers (developers) in the scrum team. Therefore a good product
owner should be able to communicate what the business need, ask why they need it (because
there may be better ways to achieve that), and convey the message to all stakeholders
including the delivery Team using a technical language, as required. The role is crucial because
the product owner needs to be technical enough to understand the architecture of the solution
in order to be credible by the Team.
Communication is a core responsibility of the product owner. The ability to convey priorities
and empathize with team members and stakeholders is vital to steer product development in
the right direction. The product owner role bridges the communication gap between the team
and its stakeholders, serving as a proxy for stakeholders to the team and as a team
representative to the overall stakeholder community.[24][25]
As the face of the team to the stakeholders, the following are some of the communication tasks
of the product owner to the stakeholders:[26]

 organize further meetings to demonstrate the solution to key stakeholders who were not
present at a sprint review;
 defines and announces releases;
 communicates delivery and team status;
 share progress during governance meetings
 share RAID (Risks, Assumptions, Issues and Dependencies) with stakeholders
 negotiates priorities, scope, funding, and schedule;
 ensures that the product backlog is visible, transparent and clear.
Empathy is a key attribute for a product owner to have—the ability to put one's self in
another's shoes. A product owner converses with different stakeholders, who have a variety of
backgrounds, job roles, and objectives. A product owner must be able to see from these
different points of view. To be effective, it is wise for a product owner to know the level of
detail the audience needs. The development team needs thorough feedback and specifications
so they can build a product up to expectation, while an executive sponsor may just need
summaries of progress. Providing more information than necessary may lose stakeholder
interest and waste time. A direct means of communication is the most preferred by seasoned
agile product owners.[22]
A product owner's ability to communicate effectively is also enhanced by being skilled in
techniques that identify stakeholder needs, negotiate priorities between stakeholder interests,
and collaborate with developers to ensure effective implementation of requirements.
Development team[edit]
The development team is responsible for delivering potentially releasable product increments
every sprint. The sprint goal is a short description of what the team is supposed to deliver at the
end of the sprint, and is important for both the Team and the stakeholders.
The team has from three to nine members who carry out all tasks required to build the product
increments (analysis, design, development, testing, technical writing, etc.).[21] Although there
will be several disciplines represented in the team, its members are referred to generically
as developers. To avoid potential confusion that this only refers to programmers, some
organizations call this a delivery team and its members just team members.
The development team in Scrum is self-organizing, and any interaction outside the team is
managed by the scrum master (who will protect the team), or the product owner (who has
regular interactions with all stakeholders).
Scrum master[edit]
Scrum is facilitated by a scrum master, who is accountable for removing impediments to the
ability of the team to deliver the product goals and deliverables. The scrum master is not a
traditional team lead or project manager but acts as a buffer between the team and any
distracting influences. The scrum master ensures that the scrum framework is followed. The
scrum master helps to ensure the team follows the agreed processes in the scrum framework,
often facilitates key sessions, and encourages the team to improve. The role has also been
referred to as a team facilitator[27] or servant-leader to reinforce these dual perspectives.
The core responsibilities of a scrum master include (but are not limited to): [28]

 Helping the product owner maintain the product backlog in a way that ensures the needed
work is well understood so the team can continually make forward progress
 Helping the team to determine the definition of done for the product, with input from key
stakeholders
 Coaching the team, within the Scrum principles, in order to deliver high-quality features for
its product
 Promoting self-organization within the team
 Helping the scrum team to avoid or remove impediments to its progress, whether internal
or external to the team
 Facilitating team events to ensure regular progress
 Educating key stakeholders on Agile and Scrum principles
 Coaching the development team in self-organization and cross-functionality
One of the ways the scrum master role differs from a project manager is that the latter may
have people management responsibilities and the scrum master does not. Scrum does not
formally recognise the role of project manager, as traditional command and control tendencies
would cause difficulties.[29]

Workflow[edit]
Sprint[edit]
A sprint (or iteration) is the basic unit of development in Scrum. The sprint is
a timeboxed effort; that is, it is restricted to a specific duration.[30][irrelevant citation] The duration is
fixed in advance for each sprint and is normally between one week and one month, with two
weeks being the most common.[2]
Each sprint starts with a sprint planning event that aims to define a sprint backlog, identify the
work for the sprint, and make an estimated forecast for the sprint goal. Each sprint ends with a
sprint review and sprint retrospective,[14] that reviews progress to show to stakeholders and
identify lessons and improvements for the next sprints.
Scrum emphasizes working product at the end of the sprint that is really done. In the case of
software, this likely includes that the software has been fully integrated, tested and
documented, and is potentially releasable.[29]
Sprint planning[edit]
At the beginning of a sprint, the scrum team holds a sprint planning event[30] to:
 Mutually discuss and agree on the scope of work that is intended to be done during that
sprint
 Select product backlog items that can be completed in one sprint
 Prepare a sprint backlog that includes the work needed to complete the selected product
backlog items
 The recommended duration is four hours for a two-week sprint (pro-rata for other sprint
durations) [16]
o During the first half, the whole scrum team (development team, scrum master, and
product owner) selects the product backlog items they believe could be completed in
that sprint
o During the second half, the development team identifies the detailed work (tasks)
required to complete those product backlog items; resulting in a confirmed sprint
backlog
 As the detailed work is elaborated, some product backlog items may be split or put
back into the product backlog if the team no longer believes they can complete the
required work in a single sprint
 Once the development team has prepared their sprint backlog, they forecast (usually by
voting) which tasks will be delivered within the sprint.
Daily scrum[edit]
Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:

 All members of the development team come prepared. The daily scrum:
o starts precisely on time even if some development team members are missing
o should happen at the same time and place every day
o is limited (timeboxed) to fifteen minutes
 Anyone is welcome, though only development team members should contribute.
 During the daily scrum, each team member typically answers three questions:
o What did I complete yesterday that contributed to the team meeting our sprint goal?
o What do I plan to complete today to contribute to the team meeting our sprint goal?
o Do I see any impediment that could prevent me or the team from meeting our sprint
goal?
Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved
unfounded)[31] identified in the daily scrum should be captured by the scrum master and
displayed on the team's scrum board or on a shared risk board, with an agreed person
designated to working toward a resolution (outside of the daily scrum). No detailed discussions
should happen during the daily scrum.
Sprint review[edit]
At the end of a sprint, the team holds two events: the sprint review and the sprint
retrospective.
At the sprint review, the team:
 reviews the work that was completed and the planned work that was not completed
 presents the completed work to the stakeholders (a.k.a. the demo)
 collaborates with the stakeholders on what to work on next
Guidelines for sprint reviews:

 Incomplete work cannot be demonstrated.

 The recommended duration is two hours for a two-week sprint (proportional for other
sprint-durations).[16]
Sprint retrospective[edit]
At the sprint retrospective, the team:

 Reflects on the past sprint

 Identifies and agrees on continuous process improvement actions
Guidelines for sprint retrospectives:

 Three main questions are asked in the sprint retrospective: What went well during the
sprint? What did not go well? What could be improved for better productivity in the next
sprint?
 The recommended duration is one-and-a-half hours for a two-week sprint (proportional for
other sprint duration(s))
 This event is facilitated by the scrum master
Extensions[edit]
The following activities are commonly done, although not considered as a core part of Scrum:
Backlog refinement[edit]
Backlog refinement (formerly called grooming) is the ongoing process of reviewing product
backlog items and checking that they are appropriately prepared and ordered in a way that
makes them clear and executable for teams once they enter sprints via the sprint planning
activity. Product backlog items may be broken into multiple smaller ones. Acceptance criteria
may be clarified. Dependencies may be identified and investigated.
Although not originally a core Scrum practice, backlog refinement has been added to the Scrum
Guide and adopted as a way of managing the quality of product backlog items entering a sprint,
with a recommended investment of up to 10% of a team's sprint capacity.[16][32]
The backlog can also include technical debt (also known as design debt or code debt). This is a
concept in software development that reflects the implied cost of additional rework caused by
choosing an easy solution now instead of using a better approach that would take longer.
Cancelling a sprint[edit]
The product owner can cancel a sprint if necessary.[16] The product owner may do so with input
from the team, scrum master or management. For instance, management may wish the
product owner to cancel a sprint if external circumstances negate the value of the sprint goal. If
a sprint is abnormally terminated, the next step is to conduct a new sprint planning, where the
reason for the termination is reviewed.

Artifacts[edit]
This section needs additional citations for verification. Please
help improve this article by adding citations to reliable sources.
Unsourced material may be challenged and removed.
Find sources: "Scrum" software development –
news · newspapers · books · scholar · JSTOR (March 2013) (Learn how
and when to remove this template message)

Product backlog[edit]
The product backlog is a model of work to be done[33] and contains an ordered list of product
requirements that a scrum team maintains for a product. The format of product backlog items
varies, common formats include user stories, use cases, or any other requirements format the
team finds useful.[29] These will define features, bug fixes, non-functional requirements, etc.—
whatever must be done to successfully deliver a viable product. The product owner prioritizes
product backlog items (PBIs) based on considerations such as risk, business value,
dependencies, size, and date needed.
The product backlog is what will be delivered, ordered into the sequence in which it should be
delivered. It is visible to everyone but may only be changed with the consent of the product
owner, who is ultimately responsible for ordering product backlog items for the development
team to choose.
The product backlog contains the product owner's assessment of business value and the
development team's assessment of development effort, which are often, but not always, stated
in story points using the rounded Fibonacci scale. These estimates help the product owner to
gauge the timeline and may influence the ordering of product backlog items; for example, if
two features have the same business value, the product owner may schedule earlier delivery of
the one with the lower development effort (because the return on investment is higher) or the
one with higher development effort (because it is more complex or riskier, and they want to
retire that risk earlier).[34]
The product backlog and the business value of each product backlog item is the responsibility of
the product owner. The effort to deliver each item is estimated by the development team in
story points, or time. By estimating in story points the product owner decouple each item from
the developer, and this can be useful especially in dynamic teams where developers are often
assigned to other projects after sprint delivery. For instance if a user story is 5 (using Fibonacci
sequence) it remains 5 regardless of how many developers are working on it. Story points
define the effort in a time-box, so they do not change with time. For instance in one hour we
can walk, run, or climb, but the effort is clearly different. Also the gap between each number in
Fibonacci (or other sequences), is suggesting the team to deliver accurate estimates. For
example 1,2 or 3 have similar efforts, 1 being trivial, but if the team estimate an 8 for 13, the
impact on both delivery and budget can be significant. the value of using story points is that we
can reuse them by comparing similar work from previous sprints, but we need to remember
that estimates are relative to the team. For instance a 5 for one team, could be a 2 for another
having senior developers and higher skills.
Every team should have a product owner, although in many instances they will work with more
than one team.[22] The product owner is responsible for maximizing the value of the product.
The product owner gathers input and takes feedback from, and is lobbied by, many people, but
ultimately makes the call on what gets built.
The product backlog:

 Captures requests to modify a product—including new features, replacing old features,

removing features, and fixing issues
 Ensures the development team has work that maximizes business benefit to the product
owner
Typically, the product owner and the scrum team come together and write down everything
that must be prioritized, and this becomes content for the first sprint—which is a block of time
meant for focused work on selected items that can be accommodated within a timeframe. The
product backlog can evolve as new information surfaces about the product and about its
customers, and so later sprints may address new work.

Management[edit]
A product backlog, in its simplest form, is merely a list of items to work on. Having well-
established rules about how work is added, removed and ordered helps the whole team make
better decisions about how to change the product.[35]
The product owner prioritizes product backlog items based on which are needed soonest. The
team then chooses which items they can complete in the coming sprint. On the scrum board,
the team moves items from the product backlog to the sprint backlog, which is the list of items
they will build. Conceptually, it is ideal for the team to only select what they think they can
accomplish from the top of the list, but it is not unusual to see in practice that teams are able to
take lower-priority items from the list along with the top ones selected. This normally happens
because there is time left within the sprint to accommodate more work. Items at the top of the
backlog, the items to work on first, should be broken down into stories that are suitable for the
development team to work on. The further down the backlog goes, the less refined the items
should be. As Schwaber and Beedle put it "The lower the priority, the less detail until you can
barely make out the backlog item."[2]
As the team works through the backlog, it must be assumed that change happens outside their
environment—the team can learn about new market opportunities to take advantage of,
competitor threats that arise, and feedback from customers that can change the way the
product was meant to work. All of these new ideas tend to trigger the team to adapt the
backlog to incorporate new knowledge. This is part of the fundamental mindset of an agile
team. The world changes, the backlog is never finished.[24]
Sprint backlog[edit]

A Scrum task board

The sprint backlog is the list of work the development team must address during the next
sprint.[36] The list is derived by the scrum team progressively selecting product backlog items in
priority order from the top of the product backlog until they feel they have enough work to fill
the sprint. The development team should keep in mind its past performance assessing its
capacity for the new-sprint, and use this as a guideline of how much 'effort' they can complete.
The product backlog items may be broken down into tasks by the development team. [36] Tasks
on the sprint backlog are never assigned (or pushed) to team members by someone else; rather
team members sign up for (or pull) tasks as needed according to the backlog priority and their
own skills and capacity. This promotes self-organization of the development team and
developer buy-in.
The sprint backlog is the property of the development team, and all included estimates are
provided by the development team. Often an accompanying task board is used to see and
change the state of the tasks of the current sprint, like to do, in progress and done.
Once a sprint backlog is committed, no additional work can be added to the sprint backlog
except by the team. Once a sprint has been delivered, the product backlog is analyzed and
reprioritized if necessary, and the next set of functionality is selected for the next sprint.
Product increment[edit]
The potentially releasable increment is the sum of all the product backlog items completed
during a sprint, integrated with the work of all previous sprints. At the end of a sprint, the
increment must be complete, according to the scrum team's definition of "done" (DoD), fully
functioning, and in a usable condition regardless of whether the product owner decides to
actually release it.
Extensions[edit]
The following artifacts are commonly used, although not considered by all as a core part of
Scrum:
Sprint burn-down chart[edit]

A sample burn-down chart for a completed sprint, showing remaining effort at the end of each
day.

Main article: Burn down chart

The sprint burn-down chart is a publicly displayed chart showing remaining work in the sprint
backlog.[37] Updated every day, it gives a simple view of the sprint progress. It also provides
quick visualizations for reference. The horizontal axis of the sprint burn-down chart shows the
days in a sprint, while the vertical axis shows the amount of work remaining each day (typically
representing the estimate of hours of work remaining).
During sprint planning, the ideal burndown chart is plotted. Then, during the sprint, each
member picks up tasks from the sprint backlog and works on them. At the end of the day, they
update the remaining hours for tasks to be completed. In such a way, the actual burndown
chart is updated day by day.
It should not be confused with an earned value chart.
Release burn-up chart[edit]

A sample burn-up chart for a release, showing scope completed each sprint
The release burn-up chart is a way for the team to provide visibility and track progress toward a
release. Updated at the end of each sprint, it shows progress toward delivering a forecast
scope. The horizontal axis of the release burn-up chart shows the sprints in a release, while the
vertical axis shows the amount of work completed at the end of each sprint (typically
representing cumulative story points of work completed). Progress is plotted as a line that
grows up to meet a horizontal line that represents the forecast scope; often shown with a
forecast, based on progress to date, that indicates how much scope might be completed by a
given release date or how many sprints it will take to complete the given scope.
The release burn-up chart makes it easy to see how much work has been completed, how much
work has been added or removed (if the horizontal scope line moves), and how much work is
left to be done.
Definition of ready (DoR)[edit]
The start-criteria to determine whether the specifications and inputs are set enough to start
the work item, i.e. a user story.
Definition of done (DoD)[edit]
The exit-criteria to determine whether a product backlog item is complete. In many cases, the
DoD requires that all regression tests be successful. The definition of done may vary from one
scrum team to another but must be consistent within one team.[38]
Velocity[edit]
The total effort a team is capable of in a sprint. The number is derived by evaluating the work
(typically in user story points) completed in the last sprint. The collection of historical velocity
data is a guideline for assisting the team in understanding how much work they can likely
achieve in a future sprint.
Spike[edit]
A time-boxed period used to research a concept or create a simple prototype. Spikes can either
be planned to take place in between sprints or, for larger teams, a spike might be accepted as
one of many sprint delivery objectives. Spikes are often introduced before the delivery of large
or complex product backlog items in order to secure budget, expand knowledge, or produce a
proof of concept. The duration and objective(s) of a spike is agreed between product owner
and development team before the start. Unlike sprint commitments, spikes may or may not
deliver tangible, shippable, valuable functionality. For example, the objective of a spike might
be to successfully reach a decision on a course of action. The spike is over when the time is up,
not necessarily when the objective has been delivered.[39]
Tracer bullet[edit]
Also called a drone spike, a tracer bullet is a spike with the current architecture, current
technology set, current set of best practices that result in production quality code. It might just
be a very narrow implementation of the functionality but is not throwaway code. It is of
production quality, and the rest of the iterations can build on this code. The name has military
origins as ammunition that makes the path of the bullet visible, allowing for corrections. Often
these implementations are a 'quick shot' through all layers of an application, such as connecting
a single form's input field to the back-end, to prove the layers connect as expected.[40]

Limitations[edit]
Scrum works less well in the following circumstances:[41][42]

 Teams whose members are geographically dispersed or part-time: In Scrum, developers

should have close and ongoing interaction, ideally working together in the same space most
of the time. While recent improvements in technology have reduced the impact of these
barriers (e.g., being able to collaborate on a digital whiteboard), the Agile manifesto asserts
that the best communication is face to face.[43]
 Teams whose members have very specialized skills: In Scrum, developers should have T-
shaped skills, allowing them to work on tasks outside of their specialization. This can be
encouraged by good Scrum leadership. While team members with very specific skills can
and do contribute well, they should be encouraged to learn more about and collaborate
with other disciplines.
 Products with many external dependencies: In Scrum, dividing product development into
short sprints requires careful planning; external dependencies, such as user acceptance
testing or coordination with other teams, can lead to delays and the failure of individual
sprints.
 Products that are mature or legacy or with regulated quality control: In Scrum, product
increments should be fully developed and tested in a single sprint; products that need large
amounts of regression testing or safety testing (e.g., medical devices or vehicle control) for
each release are less suited to short sprints than to longer waterfall releases.
From a business perspective, Scrum has many virtues, one of which is that it is designed to yield
the best business solutions. However, the efficiency by which it does so in any given
organization can vary widely and is largely dependent on the ability of the organization to
adhere to the implementation guidelines. Every company has its own distinct organizational
structure, culture, and set of business practices, and some are more naturally amenable to this
methodology than others.

2. Explain the characteristics of SCRUM team

The Product Owner

The Product Owner is responsible for maximizing the value of the product and the work of the
Development Team. It's a one-person role that brings the customer perspective of the product
to a Scrum Team.

The Product Owner is responsible for:

 Developing and maintaining a product vision and market strategy;
 Product management;
 Ordering and managing the Product Backlog;
 Involving stakeholders and end-users in Product Backlog refinement and backlog management;
 Alignment with other Product Owners when needed from an overall product, company or
customer perspective.

A Great Product Owner...

 Embraces, shares and socializes the product vision. A great Product Owner represents the
customers voice and creates a product vision together with the stakeholders. Every decision is
taken with the product vision in mind. This ensures sustainable product development, provides
clarity for the development team and increases the chances of product success drastically.
 Exceeds the customer’s expectation. A great Product Owner truly understands the customer’s
intentions and goals with the product and is able to outstrip its expectations. Customer delight
is the ultimate goal!
 Is empowered. A great Product Owner is empowered to take decisions related to the product.
Sure, creating support for his decisions might take some time, but swiftly taking important
decisions is a primary condition for a sustainable pace of the development team.
 Orders the product backlog. A great Product Owner understands that the product backlog
should be ordered. Priority, risk, value, learning opportunities and dependencies are all taken
into account and balanced with each other. For example, when building a house the roof might
have the highest priority considering possible rain. But still it's necessary to realize the
foundation and walls earlier and therefore order them above the construction of the roof.
 Prefers face-to-face communication. A great Product Owner understands that the best way to
convey information is face-to-face communication. User stories are explained in a personal
conversation. If a tool is used for backlog management, its function is to support the dialogue. It
never replaces the good old-fashioned conversation.
 Knows modeling techniques. A great Product Owner has a backpack full of valuable modeling
techniques. He knows when to apply a specific model. Examples are Business Model
Generation, Lean Startup or Impact Mapping. Based on these models he knows how to drive
product success.
 Shares experiences. A great Product Owner shares experiences with peers. This might be within
the organization, and outside it: seminars and conferences are a great way to share experiences
and gather knowledge. In addition, writing down your lessons learned can be valuable for other
Product Owners.
 Owns user story mapping. A great Product Owner should master the concept of user story
mapping. It's a technique that allows you to add a second dimension to your backlog. The
visualization enables you to see the big picture of the product backlog. Jeff Patton wrote some
excellent material about the concept of story mapping.
 Has a focus on functionality. A great Product Owner has a focus on functionality and the non-
functional aspects of the product. Hours or even story points are less important. The goal of the
Product Owner is to maximize value for the customer. It’s the functionality that has value;
therefore this is the main focus for the Product Owner.
 Is knowledgeable. A great Product Owner has in depth (non-)functional product knowledge and
understands the technical composition. For large products it might be difficult to understand all
the details, and scaling the Product Owner role might be an option. However the Product
Owner should always know the larger pieces of the puzzle and hereby make conscious, solid
decisions.
 Understands the business domain. A great Product Owner understands the domain and
environment he's part of. A product should always be build with its context taken into account.
This includes understanding the organization paying for the development but also being aware
of the latest the market conditions. Shipping an awesome product after the window of
opportunity closes is quite useless.
 Acts on different levels. A great Product Owner knows how to act on different levels. The most
common way to define these levels is strategic, tactical and operational. A Product Owner
should know how to explain the product strategy at board level, create support at middle
management and motivate the development team with their daily challenges.
 Knows the 5 levels of Agile planning. Within Agile, planning is done continuously. Every
product needs a vision (level 1) which will provide input to the product roadmap (level 2). The
roadmap is a long range strategic plan of how the business would like to see the product
evolve. Based on the roadmap, market conditions and status of the product the Product Owner
can plan releases (level 3). During the Sprint Planning (level 4) the team plan and agree on
Product Backlog Items they are confident they can complete during the Sprint and help them
achieve the Sprint Goal. The Daily Scrum (level 5) is used to inspect and adapt the team's
progress towards realizing the Sprint Goal.
 Is available. A great Product Owner is available to the stakeholders, the customers, the
development team and the Scrum Master. Important questions are answered quickly and
valuable information is provided on time. The Product Owner ensures his availability never
blocks the progress of the development team.
 Is able to say 'no'. A great Product Owner knows how and when to say no. This is probably the
most obvious but most difficult characteristic to master. Saying yes to a new idea or feature is
easy, it's just another item for the product backlog. However, good backlog management
encompasses creating a manageable product backlog with items that probably will get realized.
Adding items to the backlog knowing nothing will happen with them only creates 'waste' and
false expectations.
 Acts as a "Mini-CEO". A great Product Owner basically is a mini-CEO for his product. He has a
keen eye for opportunities, focuses on business value and the Return On Investment and acts
proactive on possible risks and threats. Everything with the growth (size, quality, market share)
of his product taken into account.
 Knows the different types of valid Product Backlog items. A great Product Owner can clarify
the fact that the Product Backlog consists of more than only new features. Fore example:
technical innovation, bugs, defects, non-functional requirements and experiments, should also
be taken into account.
 Takes Backlog Refinement seriously. A great Product Owner spends enough time refining the
Product Backlog. Backlog Refinement is the act of adding detail, estimates and order to items in
the Product Backlog. The outcome should be a Product Backlog that is granular enough and
well understood by the whole team. On average the Development Team spends no more than
10% of the capacity of the Development Team on refinement activities. The way it is done isn’t
prescribed and is up to the team. The Product Owner can involve stakeholders and the
Development Team in backlog refinement. The stakeholders because it gives them the
opportunity to explain their wishes and desires. The Development Team because they can
clarify functional and technical questions or implications. This will ensure common
understanding and increases the quality of the Product Backlog considerably. As a
consequence, the opportunity to build the right product with the desired quality will also
increase.

The Scrum Master

According to the Scrum Guide the Scrum Master is responsible for ensuring Scrum is
understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to
Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
The Scrum Master helps those outside the Scrum Team understand which of their interactions
with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change
these interactions to maximize the value created by the Scrum Team.

The role of a Scrum Master is one of many stances and diversity. A great Scrum Master is aware
of them and knows when and how to apply them, depending on situation and context.
Everything with the purpose of helping people understand and apply the Scrum framework
better.

The Scrum Master acts as a:

 Servant Leader whose focus is on the needs of the team members and those they serve (the
customer), with the goal of achieving results in line with the organization's values, principles,
and business objectives;
 Facilitator by setting the stage and providing clear boundaries in which the team can
collaborate;
 Coach coaching the individual with a focus on mindset and behaviour, the team in continuous
improvement and the organization in truly collaborating with the Scrum team;
 Conflict navigator to address unproductive attitudes and dysfunctional behaviors;
 Manager responsible for managing impediments, eliminate waste, managing the process,
managing the team's health, managing the boundaries of self-organization, and managing the
culture;
 Mentor that transfers agile knowledge and experience to the team;
 Teacher to ensure Scrum and other relevant methods are understood and enacted.
 A Great Scrum Master...

 Involves the team with setting up the process. A great Scrum Master ensures the entire team
supports the chosen Scrum process and understands the value of every event. The daily Scrum
for example is planned at a time that suits all team members. A common concern about Scrum
is the amount of 'meetings', involving the team with planning the events and discussing the
desired outcome will increase engagement for sure.
 Understands team development. A great Scrum Master is aware of the different phases a team
will go through when working as a team. He understands Tuckman's different stages of team
development: forming, storming, norming, performing and adjourning. The importance of a
stable team composition is therefore also clear.
 Understands principles are more important than practices. Without a solid, supported
understanding of the agile principles, every implemented practice is basically useless. It's an
empty shell. An in-depth understanding of the agile principles by everyone involved will
increase the chances of successful usage of practices drastically.
 Recognizes and acts on team conflict. A great Scrum Master recognizes team conflict in an
early stage and can apply different activities to resolve it. A great Scrum Master understands
conflict isn't necessarily wrong. Healthy conflict and constructive disagreement can be used to
build an even stronger team.
 Dares to be disruptive. A great Scrum Master understands some changes will only occur by
being disruptive. He knows when it's necessary and is prepared to be disruptive enough to
enforce a change within the organization.
 Is aware of the smell of the place. A great Scrum Master can have an impact on the culture of
the organization so that the Scrum teams can really flourish. He understands that changing
people's behavior isn't about changing people, but changing the context which they are in:
the smell of the place.
 Is both dispensable and wanted. A great Scrum Master has supported the growth of teams in
such a manner they don't need him anymore on daily basis. But due to his proven contribution
he will get asked for advice frequently. His role has changed from a daily coach and teacher to a
periodical mentor and advisor.
 Let his team fail (occasionally). A great Scrum Master knows when to prevent the team from
failing but also understands when he shouldn't prevent it. The lessons learned after a mistake
might be more valuable than some good advice beforehand.
 Encourages ownership. A great Scrum Master encourages and coaches the team to take
ownership of their process, task wall and environment.
 Has faith in self-organization. A great Scrum Master understands the power of a self-organizing
team. "Bring it to the team" is his daily motto. Attributes of self-organizing teams are that
employees reduce their dependency on management and increase ownership of the work.
Some examples are: they make their own decisions about their work, estimate their own work,
have a strong willingness to cooperate and team members feel they are coming together to
achieve a common purpose through release goals, sprint goals and team goals.
 Values rhythm. A great Scrum Master understands the value of a steady sprint rhythm and
does everything to create and maintain it. The sprint rhythm should become the team’s
heartbeat, which doesn't cost any energy. Everyone knows the date, time and purpose of every
 Scrum event. They know what is expected and how to prepare. Therefore a complete focus on
the content is possible.
 Knows the power of silence. A great Scrum Master knows how to truly listen and is
comfortable with silence. Not talking, but listening. He is aware of the three levels of listening -
level 1 internal listening, level 2 focused listening, level 3 global listening, and knows how to use
them. He listens carefully to what is said, but also to what isn't said.
 Observes. A great Scrum Master observes his team with their daily activities. He doesn't have
an active role within every session. The daily Scrum, for example, is held by the team for the
team. He observes the session and hereby has a more clear view to what is being discussed
(and what isn't) and what everyone’s role is during the standup.
 Shares experiences. Great Scrum Masters shares experiences with peers. This might be within
the organization, but also seminars and conferences are a great way to share experiences and
gather knowledge. Of course writing down and sharing your lessons learned is also highly
appreciated. And yes, for the attentive readers, this is exactly the same as for the Product
Owner and the Development Team.
 Has a backpack full of different retrospective formats. A great Scrum Master can apply lots of
different retrospective format. This ensures the retrospective will be a fun and useful event for
the team. He knows what format is most suitable given the team's situation. Even better: he
supports the team by hosting their own retrospective. To improve involvement this is an
absolute winner!
 Can coach professionally. A great Scrum Master understands the power of professional
coaching and has mastered this area of study. Books like Coaching Agile Teams and Co-Active
Coaching don't have any secrets for him. He knows how to guide without prescribing. He can
close the gap between thinking about doing and actually doing; he can help the team members
understand themselves better so they can find news ways to make the most of their potential.
Yes, these last few sentences are actually an aggregation of several coaching definitions, but it
sounds quite cool!
 Has influence at organizational level. A great Scrum Master knows how to motivate and
influence at tactic and strategic level. Some of the most difficult impediments a team will face
occur at these levels; therefore it's important a Scrum Master knows how to act at the different
levels within an organization.
 Prevent impediments. A great Scrum Master not only resolves impediments, he prevents them.
Due to his experiences he is able to 'read' situations and hereby act on them proactively.
 Isn't noticed. A great Scrum Master isn't always actively present. He doesn't disturb the team
unnecessary and supports the team in getting into the desired 'flow'. But when the team needs
him, he's always available.
 Forms a great duo with the Product Owner. A great Scrum Master has an outstanding
partnership with the Product Owner. Although their interests are somewhat different, the
Product Owner 'pushes' the team, the Scrum Master protects the team. A solid partnership is
extremely valuable for the Development Team. Together they can build the foundation for
astonishing results.
 Allows leadership to thrive. A great Scrum Master allows leadership within the team to thrive
and sees this as a successful outcome of their coaching style. They believe in the motto
 "leadership isn't just a title, it's an attitude". And it's an attitude everyone in the team can
apply.
 Is familiar with gamification. A great Scrum Master is able to use the concepts of game thinking
and game mechanics to engage users in solving problems and increase users' contribution.
 Understands there's more than just Scrum. A great Scrum Master is also competent with XP,
Kanban and Lean. He knows the strengths, weaknesses, opportunities and risks of every
method/framework/principle and how & when to use them. He tries to understand what a
team wants to achieve and helps them become more effective in an agile context.
 Leads by example. A great Scrum Master is someone that team members want to follow. He
does this by inspiring them to unleash their inner potential and showing them the desired
behavior. At difficult times, he shows them how to act on it; he doesn't panic, stays calm and
helps the team find the solution. Therefore a great Scrum Master should have some
resemblance to Gandalf. The beard might be a good starting point :)
 Is a born facilitator. A great Scrum Master has facilitation as his second nature. All the Scrum
events are a joy to attend, and every other meeting is well prepared, useful and fun, and has a
clear outcome and purpose.

The Development Team

According to the Scrum Guide the Development Team consists of professionals who do the
work of delivering a potentially releasable Increment of “Done” product at the end of each
Sprint. Only members of the Development Team create the Increment. Development Teams are
structured and empowered by the organization to organize and manage their own work. The
resulting synergy optimizes the Development Team’s overall efficiency and effectiveness.

Development Teams have the following characteristics:

 Self-organizing. They decide how to turn Product Backlog Items into working solutions.
 Cross-functional. As a whole, they've got all the skills necessary to create the product
Increment.
 No titles. Everyone is a Developer, no one has a special title.
 No sub-teams in the Development team.
 Committed to achieving the Sprint Goal and delivering a high quality increment

A Great Development Team

 Pursues technical excellence. Great Development Teams use Extreme Programming as a source
of inspiration. XP provides practices and rules that revolve around planning, designing, coding
and testing. Examples are refactoring (continuously streamlining the code), pair programming,
continuous integration (programmers merge their code into a code baseline whenever they
 have a clean build that has passed the unit tests), unit testing (testing code at development
level) and acceptance testing (establishing specific acceptance tests).
 Applies team swarming. Great Development Teams master the concept of 'team swarming'.
This is a method of working where a team works on just a few items at a time, preferably even
one item at a time. Each item is finished as quickly as possible by having many people work on
it together, rather than having a series of handoffs.
 Uses spike solutions. A spike is a concise, timeboxed activity used to discover work needed to
accomplish a large ambiguous task. Great Development Teams uses spike experiments to solve
challenging technical, architectural or design problems.
 Refines the product backlog as a team. Great Development Teams consider backlog
refinement a team effort. They understand that the quality of the Product Backlog is the
foundation for a sustainable development pace and building great products. Although the
Product Owner is responsible for the product backlog, it's up to the entire team to refine it.
 Respects the Boy Scout Rule. Great Development Teams use the Boy Scout Rule: always leave
the campground cleaner than you found it. Translated to software development: always leave
the code base in a better state than you've found it. If you find messy code, clean it up,
regardless of who might have made the mess.
 Criticizes ideas, not people. Great Development Teams criticize ideas, not people. Period.
 Share experiences. Great Development Teams share experiences with peers. This might be
within the organization, but also seminars and conferences are a great way to share
experiences and gather knowledge. Of course writing down and sharing your lessons learned is
also highly appreciated. And yes, for the attentive readers, this is exactly the same as for the
Product Owner.
 Understands the importance of having some slack. Great Development Teams have some slack
within their sprint. Human beings can't be productive all day long. They need time to relax,
have a chat at the coffee machine or play table football. They need some slack to be innovative
and creative. They need time to have some fun. By doing so, they ensure high motivation and
maximum productivity. But slack is also necessary to handle emergencies that might arise; you
don't want your entire sprint to get into trouble when you need to create a hot-fix. Therefore:
build in some slack! And when the sprint doesn't contain any emergencies: great! This gives the
team the opportunity for some refactoring and emergent design. It's a win-win!
 Has fun with each other. Great Development Teams ensure a healthy dose of fun is present
every day. Fostering fun, energy, interaction and collaboration creates an atmosphere in which
the team will flourish!
 Don't have any Scrum 'meetings'. Great Development Teams consider the Scrum events as
opportunities for conversations. Tobias Mayer describes this perfectly in his book ‘The Peoples
Scrum': “Scrum is centered on people, and people have conversations. There are conversations
to plan, align, and to reflect. We have these conversations at the appropriate times, and for the
appropriate durations in order to inform our work. If we don’t have these conversations, we
won’t know what we are doing (planning), we won’t know where we are going (alignment), and
we’ll keep repeating the same mistakes (reflection).”
 Knows their customer. Great Development Teams know their real customer. They are in direct
contact with them. They truly understand what they desire and are therefore able to make the
right (technical) decisions.
 Can explain the (business) value of non-functional requirements. Great Development Teams
understand the importance for non-functional requirements like e.g. performance, security and
scalability. They can explain the (business) value to their Product Owner and customer and
hereby ensure its part of the product backlog.
 Trust each other. Great Development Teams trust each other. Yes, this is obvious. But without
trust it's impossible for a team to achieve greatness.
 Keep the retrospective fun. Great Development Teams think of retrospective formats
themselves. They support the Scrum Master with creative, fun and useful formats and offer to
facilitate the sessions themselves.
 Deliver features during the sprint. Great Development Teams deliver features continuously.
Basically they don't need sprints anymore. Feedback is gathered and processed whenever an
item is ‘done’; this creates a flow of continuous delivery.
 Don't need a sprint 0. Great Development Teams don't need a sprint 0 before the 'real' sprints
start. They are able to deliver business value in the first sprint.
 Acts truly cross-functional. Great Development Teams not only have a cross-functional
composition and act truly cross-functionally. They don't talk about different roles within the
team but are focused on delivering a releasable product each sprint as a team. Everyone is
doing the stuff that's necessary to achieve the sprint goal.
 Updates the Scrum board themselves. Great Development Teams ensure the Scrum/team
board is always up-to-date. It's an accurate reflection of the reality. They don't need a Scrum
Master to encourage them; instead they collaborate with the Scrum Master to update the
board.
 Spends time on innovation. Great Development Teams understand the importance of
technical/architectural innovation. They know it's necessary to keep up with the rapidly
changing environment and technology. They ensure they have time for innovation during
regular working hours, and that it's fun and exciting!
 Don't need a Definition of Done. Great Development Teams deeply understand what 'done'
means for them. For the team members, writing down the Definition of Done isn't necessary
anymore. They know. The only reason to use it is to make the 'done state' transparent for their
stakeholders.
 Knows how to give feedback. Great Development Teams have learned how to give each other
feedback in an honest and respectful manner. They grasp the concept of the 'Situation -
Behavior - Impact Feedback Tool' and hereby provide clear, actionable feedback. They give
feedback whenever it's necessary, and don't postpone feedback until the retrospective.
 Manages their team composition. Great Development Teams manage their own team
composition. Whenever specific skills are necessary, they collaborate with other teams to
discuss the opportunities of 'hiring' specific skills.
 Practice collective ownership. Great Development Teams understand the importance of
collective ownership. Therefore they rotate developers across different modules of the
applications and systems to encourage collective ownership.
 Fix dependencies with other teams. Great Development Teams are aware of possible
dependencies with other teams and manage these by themselves. Thereby ensuring a
sustainable development pace for the product.
 Don't need story points. Great Development Teams don't focus on story points anymore.
They've refined the product backlog so that the size for the top items don’t vary much. They
know how many items they can realize each sprint. Counting the number of stories is enough
for them.

3. Daily SCRUM(refer scrum qn)

4. Burn down chart(refer scrum qn)
5. Project velocity(refer scrum qn)
6. User stories

User stories are one of the primary development artifacts for Scrum and Extreme Programming
(XP) project teams. A user story is a very high-level definition of a requirement, containing just
enough information so that the developers can produce a reasonable estimate of the effort to
implement it. This article covers the following topics:

 Introduction to user stories

 Initial user stories (informal)
 Initial user stories (formal)
 User stories and planning
 User stories throughout the agile lifecycle
 Detailing a user story
 Epics
 Themes

1. Introduction to User Stories

A good way to think about a user story is that it is a reminder to have a conversation with your
customer (in XP, project stakeholders are called customers), which is another way to say it's a
reminder to do some just-in-time analysis. In short, user stories are very slim and high-level
requirements artifacts.

2. Initial User Stories (Informal)

As you can see in Figure 1 user stories are small, much smaller than other usage requirement
artifacts such as use cases or usage scenarios. It's important to recognize that each of the
statements in Figure 1 represents a single user story.

Figure 1. Example user stories.

 Students can
purchase monthly
parking passes
 online.
 Parking passes can
be paid via credit
cards.
 Parking passes can
be paid via PayPal.
 Professors can input
student marks.
 Students can obtain
their current
seminar schedule.
 Students can order
official transcripts.
 Students can only
enroll in seminars
for which they have
prerequisites.
 Transcripts will be
available online via a
standard browser.

Important considerations for writing user stories:

1. Stakeholders write user stories. An important concept is that your project stakeholders
write the user stories, not the developers. User stories are simple enough that people
can learn to write them in a few minutes, so it makes sense that the domain experts
(the stakeholders) write them.
2. Use the simplest tool. User stories are often written on index cards as you see in Figure
2 (at least when your project team is co-located). Index cards are very easy to work with
and are therefore an inclusive modelingtechnique.
3. Remember non-functional requirements. Stories can be used to describe a wide variety
of requirements types. For example in Figure 1 the Students can purchase parking
passes online user story is a usage requirement similar to a use case whereas
the Transcripts will be available online via a standard browser is closer to a technical
requirement.
4. Indicate the estimated size. You can see in Figure 2 that it includes an estimate for the
effort to implement the user story. One way to estimate is to assign user story points to
each card, a relative indication of how long it will take a pair of programmers to
implement the story. The team then knows that if it currently takes them on average 2.5
hours per point; therefore the user story in Figure 2 will take around 10 hours to
implement.
 5. Indicate the priority. Requirements, including defects identified as part of
your independent parallel testing activities or by your operations and support efforts,
are prioritized by your project stakeholders (or representatives thereof such as product
owners) and added to the stack in the appropriate place. You can easily maintain a stack
of prioritized requirements by moving the cards around in the stack as appropriate. You
can see that the user story card includes an indication of the priority; I often use a scale
of one to ten with one being the highest priority. Other prioritization approaches are
possible – priorities of High/Medium/Low are often used instead of numbers and some
people will even assign each card it's own unique priority order number (e.g. 344, 345,
…). You want to indicate the priority somehow in case you drop the deck of cards, or if
you're using more sophisticated electronic tooling. Pick a strategy that works well for
your team. You also see that the priority changed at some point in the past, this is a
normal thing, motivating the team to move the card to another point in the stack. The
implication is that your prioritization strategy needs to support this sort of activity. My
advice is to keep it simple.
6. Optionally include a unique identifier. The card also includes a unique identifier for the
user story, in this case 173. The only reason to do this would be to do this is if you need
to maintain some sort of traceability between the user story and other artifacts, in
particular acceptance tests.

Figure 2. User story card (informal, high level).

2. Initial User Stories (Formal)

In User Stories Applied Mike Cohn suggests a more formal approach to
writing user stories. He suggests the format:

As a (role) I want (something) so that (benefit).

For example, the user story of Figure 2 could be rewritten as "As a Student I
want to purchase a parking pass so that I can drive to school", as you see
in Figure 3. My experience is that this approach helps you to think about who
a certain feature is built for and why, and as a result is the approach that I
typically prefer to take. The best advice that I can give is to try both and see
which approach works best for you.

Figure 3. User story card (formal, high level).

4. User Stories and Planning

There are two areas where user stories affect the planning process on agile projects:

1. Scheduling. Figure 4 depicts the agile change management management process where
work items, including stories, are addressed in priority order. So, the implication is that
the priority assigned to a story affects when the work will be done to implement that
requirement. As discussed earlier, project stakeholders are responsible for prioritizing
requirements. Note that in Figure 2 a numerical prioritization strategy was taken
(perhaps on a scale of 1 to 20) whereas in Figure 3 a MoSCoW (Must Should Could
Won't) approach was used. Stakeholders also have the right to define new
requirements, change their minds about existing requirements, and even reprioritize
requirements as they see fit. However, stakeholders must also be responsible for
making decisions and providing information in a timely manner.
 2. Estimating. Developers are responsible for estimating the effort required to implement
the things which they will work on, including stories. The implication is that because you
can only do so much work in an iteration, the size of the work items (including stories),
affect when those work items will be addressed. Although you may fear that developers
don't have the requisite estimating skills, and this is often true at first, the fact is that it
doesn't take long for people to get pretty good at estimating when they know that
they're going to have to live up to those estimates. If you've adopted the pair
programming practice then a user story must be able to be implemented by two people
in a single iteration/sprint. Therefore if you're working in one week iterations each user
story must describe less than one week worth of work. Of course, if you aren't taking a
non-solo development approach such as pair programming the user story would need to
be implementable by a single person within a single iteration. Large stories, sometimes
called epics, would need to be broken up into smaller stories to meet this criteria.

Figure 4. Disciplined agile change management process.

5. User Stories Throughout the Agile Life Cycle

As you can see in the Disciplined Agile Delivery (DAD) life cycle of Figure 5, there are several
distinct "phases" or seasons in the life cycle (some people will refer to the agile delivery life
cycle as a release rhythm). Figure 6 depicts the AMDD project life cycle, which calls out
modeling activities during the delivery life cycle. There are three common times when stories
will be worked on during an agile project:

1. Inception. You often create a stack of user stories during Inception as part of
your requirements envisioning activities to identify the scope of your system.
2. Construction. During construction iterations you will identify new stories, split existing
stories when you realize that they're too large to be implemented in single iteration,
reprioritize existing stories, or remove stories that are no longer considered to be in
scope. The point is that your stories evolve over time just like other types of
requirements models evolve. Furthermore, enhancement requests may be identified by
your support staff during theproduction phase and then forwarded to a development
team as they are working on an upcoming release. These enhancement requests are
effectively new stories (albeit in a different format).
3. Transition. Sometimes new stories will be identified during the Transition phase,
although this isn't very common as the focus of release is on hardening the system and
not on new functionality. But it does happen, and these stories would be prioritized and
placed on the stack in priority order just as you normally would.

Figure 5. The Extended DAD lifecycle.

Figure 6. The AMDD lifecycle: Modeling activities throughout the life cycle of a project.
6. Detailing a User Story

Because user stories contain so little information you will need to flesh them out a bit when you
first work with them. There are three common times when you would do this:

1. During JIT analysis/model storming with stakeholders. Remember the early definition
of "user stories are a reminder to have a conversation with your stakeholders"? Well,
during that conversation you're going to explore the details behind that user story. It is
quite common the create screen sketches with stakeholders to explore what they want.
It is also common to identify the acceptance criteria, or confirmations, which the
stakeholders will use to validate that the user story has been implemented
correctly. Figure 7 shows how the back side of a user story card can be used to capture
the confirmations. Of course, other tools which are more sophisticated than index cards
can be used for this purpose as well.
 2. During iteration planning. As part of the estimation effort it is quite common to list
programming tasks required to implement the user story.
3. During implementation. When you start to work on implementing the user story you
may decide to create some rough sketches of what you're going to build, perhaps a flow
chart or UML activity diagram representing the relevant business logic.

Figure 7. User story card (formal, with confirmations).

7. Epics

Epics are large user stories, typically ones which are too big to implement in a single iteration
and therefore they need to be disaggregated into smaller user stories at some point.

Epics are typically lower priority user stories because once the epic works its way towards the
top of the work item stack, see Figure 4, it is reorganized into smaller ones. It doesn't make
sense to disaggregate a low-priority epic because you'd be investing time on something which
you may never get to addressing, unless a portion of the epic is high priority and needs to be
teased out. Remember to defer commitment, in this case model on a just-in-time (JIT) basis, to
increase your overall productivity.

8. Themes

A theme is a collection of related user stories. For example, for a university registration system
there might be themes around students, course management, transcript generation, grade
administration, financial processing.
Themes are often used to organize stories into releases or to organize them so that various
subteams can work on them.

7. SCRUM is instrumental and interactive justify this statement(refer scrum qn)

8. What is sprint and how the velocity of sprint measured(refer scrum qn)
9. Explain the characteristics of good user stories

User Story Characteristics

Here is a short, but informative list of user story characteristics.

 A good user story should be complete enough to provide a user with some value.
 The good user story should be user-centric, normally people write user story too much
centric around components or system aspects.
 When writing a user story, focus on what the user is doing or getting out of the story.
 The goal is that, when the user story is done, the user story has some value for users.
 Group the user stories which offers a feature in same domain, or its good to grouping a
certain feature or use case into a single or multiple Epics.
 A good user story is written in one to three lines.
 Some user stories have attached files to elaborate the user story more clearly.
 Good user story is well-defined, well-detailed and comprehensive.
 A good user story is helpful to capture a specific functionality.
 Involvement of development team in the user story is important.
 A good user story is simple and concise.
 Good user story should always be in active voice. Do not use ambiguous and confusing
terms.
 Good user story only focus on important part and leave out the rest.
 Start with an epic, when writing a user story about new product and feature because it
allow to capture the rough idea about product with less detail.
 User Stories are used to communicate information, so make them visible and accessible.
 Good user stories are complemented with other techniques like, story maps, sketches,
mockups, storyboards and workflow diagrams etc.
 Try to avoid dependencies between stories, dependencies between stories will have
priority and planning issues.
 The story should be negotiable. User story should be changed or removed without
impact to everything else.
  The best valuable user story is that one, which is written by user or customer. Give value
to each user story which writes by user of customer.
 Developers should be able to predict (at least rough guess). They predict about time
scale of stories , and to achieve the desired encoding.
 The story of scale is depend on team size, capacity development group , as well as
technical realization.
 Good user story is a story which is easily testable. We cannot develop, what we cannot
test. A non-testable user story is : “software should be easy and pleasant to use”.
There are two helping methods for writing user stories:

 Invest (This technique is helpful for user story)

 Smart (SMART is for the tasks of a user story)

Bill Wake’s user story Characteristics:

To build a good user story , we focus on six characteristics. A good story should have
characteristics. Bill Wake described six characteristics of a good user story. We entitle his
formula as “Invest”.

Invest

 I) Independent
 N) Negotiable
 V) Valuable
 E) Estimable
 S) Small
 T) Testable

Independent

We must try to avoid the interdependence between the story. When the story prioritize, plan
to do or when to use the story, the story of the interdependence between the estimated
workload will cause more difficult. Usually we can reduce the dependence of two ways:

 Interdependent story combined into a large, separate stories

 With a different way to split the story

Negotiable

Story card is a brief description of the function, the details of the discussion will result in
customers and development teams in. The story is a reminder of the role of card developers
and customers to engage in dialogue on demand, it is not a skill specific needs. A user story is a
cassette with too many details, effectively limiting and user communication.

Valuable

User Stories should clearly reflect the values of the user or customers, the best approach is to
allow customers to write the story. Once a client realize that this user story is not in contract
and can be negotiated, they will be happy to write the story.

Estimatable:

Development team needs to estimate a user story in order to determine priorities, workload
scheduling. But let developers is difficult to estimate story Problems from:

 Developer lack of domain knowledge

 Developers lack of technical knowledge
Story too . . . .

Small

A good story on the amount of work to be as small as possible , preferably not more than 10
people over the workload / day, at least make sure that in one iteration or Sprint that can be
completed. User Stories larger scheme of arrangement at risk , effort estimation and other
aspects will be.

Testable

The story must be testable . Successfully passed the test developers can prove that correctly
implements the story. If a user is not able to test the story , then you will not know when it can
be done . An example of a non- test user stories : The user must find the software very easy to
use.

Related: Agile User Stories and Groomed Product Backlog

Smart:

SMART is not for user stories but for the tasks of a user story.

 S) Specific
 M) Measurable
 A) Achievable
 R) Relevant
 T) Time-Boxed
Specific

A task needs to be specific enough so that everyone can understand it. It helps to keep other
tasks from overlapping, and also helps people to understand either the tasks add up to the full
story or not.

Measurable

The key of measure is, “can we mark it as done?” Team needs to agree on what that means, but
it should also include:

 “what it is intended to”

 “tests are included,”
 “the code has been refactored.”

Achievable

The task owner must be able to achieve task. In XP methodology, teams have a rule, in which
anybody can ask for help whenever they need; this is certainly includes ensuring that task
owners are up to the job.

Relevant

Every task must be relevant and story contributing. User stories are broken into tasks for the
developers benefit, but customer should still be able to expect that each task can be justified
and explained.

Time-Boxed

A task should be limited to a specific duration. This doesn’t need to be a formal estimate in
hours or days, but there must be an expectation so people know, when they should seek help.
If a task is harder than expectation, then the team needs to split the task, change players, or do
something to help the task (and story) to get done.

10. How agile estimation and planning is done? Explain planning poker
Agile teams use straightforward planning tools to get a handle on their projects. Scrum teams
plan their projects together so that everybody on the team commits to each sprint’s goal. To
maintain the team’s collective commitment, planning, estimating, and tracking need to be
simple and easy for the whole team to do as a group. From user stories and planning
pokerto velocity and burndown charts, Scrum teams always know what they’ve done and
what’s left to do.

What is Planning Poker?

Planning Poker is an agile estimating and planning technique that is consensus based. To start a
poker planning session, the product owner or customer reads an agile user story or describes a
feature to the estimators.

Each estimator is holding a deck of Planning Poker cards with values like 0, 1, 2, 3, 5, 8, 13, 20,
40 and 100, which is the sequence we recommend. The values represent the number of story
points, ideal days, or other units in which the team estimates.

The estimators discuss the feature, asking questions of the product owner as needed. When the
feature has been fully discussed, each estimator privately selects one card to represent his or
her estimate. All cards are then revealed at the same time.

If all estimators selected the same value, that becomes the estimate. If not, the estimators
discuss their estimates. The high and low estimators should especially share their reasons. After
further discussion, each estimator reselects an estimate card, and all cards are again revealed
at the same time.

The poker planning process is repeated until consensus is achieved or until the estimators
decide that agile estimating and planning of a particular item needs to be deferred until
additional information can be acquired.

When should we engage in Planning Poker?

Most teams will hold a Planning Poker session shortly after an initial product backlog is written.
This session (which may be spread over multiple days) is used to create initial estimates useful
in scoping or sizing the project.

Because product backlog items (usually in the form of user stories) will continue to be added
throughout the project, most teams will find it helpful to conduct subsequent agile estimating
and planning sessions once per iteration. Usually this is done a few days before the end of the
iteration and immediately following a daily standup, since the whole team is together at that
time anyway.

How does poker planning work with a distributed team?

Simple: go to PlanningPoker.com. Mountain Goat Software helped develop that website to
offer it as a free resource to the agile community. A product owner, ScrumMaster or agile coach
can log in and preload a set of items to be estimated. A private URL can then be shared with
estimators who log in and join a conference call or Skype session. Agile estimating and planning
then proceeds as it would in person.

Does Planning Poker work?

Absolutely. Teams estimating with Planning Poker consistently report that they arrive at more
accurate estimates than with any technique they'd used before.

One reason Planning Poker leads to better estimates is because it brings together multiple
expert opinions. Because these experts form a cross-functional team from all disciplines on a
software project, they are better suited to the estimation task than anyone else.

After completing a thorough review of the literature on software estimation, Magne Jørgensen,
Ph.D., of the Simula Research Lab concluded that “the people most competent in solving the
task should estimate it.”

Second, a lively dialogue ensues during poker planning, and estimators are called upon by their
peers to justify their estimates. Researchers have found that this improves estimate accuracy,
especially on items with a lot of uncertainty as we find on most software projects.

Further, being asked to justify estimates has also been shown to result in estimates that better
compensate for missing information. This is important on an agile project because the user
stories being estimated are often intentionally vague.

Additionally, studies have shown that averaging individual estimates during agile estimating
and planning leads to better results as do group discussions of estimates.

11. Explain following meeting of SCRUM

 a. Sprint planning

At the beginning of a sprint, the scrum team holds a sprint planning event [30] to:

 Mutually discuss and agree on the scope of work that is intended to be done during that
sprint
 Select product backlog items that can be completed in one sprint
 Prepare a sprint backlog that includes the work needed to complete the selected product
backlog items
 The recommended duration is four hours for a two-week sprint (pro-rata for other sprint
durations) [16]
o During the first half, the whole scrum team (development team, scrum master, and
product owner) selects the product backlog items they believe could be completed in
that sprint
o During the second half, the development team identifies the detailed work (tasks)
required to complete those product backlog items; resulting in a confirmed sprint
backlog
 As the detailed work is elaborated, some product backlog items may be split or put
back into the product backlog if the team no longer believes they can complete the
required work in a single sprint
 Once the development team has prepared their sprint backlog, they forecast (usually by
voting) which tasks will be delivered within the sprint.

b. Sprint review

At the end of a sprint, the team holds two events: the sprint review and the sprint
retrospective.
At the sprint review, the team:

 reviews the work that was completed and the planned work that was not completed
 presents the completed work to the stakeholders (a.k.a. the demo)
 collaborates with the stakeholders on what to work on next
Guidelines for sprint reviews:

 Incomplete work cannot be demonstrated.

 The recommended duration is two hours for a two-week sprint (proportional for other
sprint-durations).[16]
c. Sprint retrospective

At the sprint retrospective, the team:

 Reflects on the past sprint
 Identifies and agrees on continuous process improvement actions
Guidelines for sprint retrospectives:

 Three main questions are asked in the sprint retrospective: What went well during the
sprint? What did not go well? What could be improved for better productivity in the next
sprint?
 The recommended duration is one-and-a-half hours for a two-week sprint (proportional for
other sprint duration(s))
 This event is facilitated by the scrum master

d. Daily scrum

Each day during a sprint, the team holds a daily scrum (or stand-up) with specific guidelines:

 All members of the development team come prepared. The daily scrum:
o starts precisely on time even if some development team members are missing
o should happen at the same time and place every day
o is limited (timeboxed) to fifteen minutes
 Anyone is welcome, though only development team members should contribute.
 During the daily scrum, each team member typically answers three questions:
o What did I complete yesterday that contributed to the team meeting our sprint goal?
o What do I plan to complete today to contribute to the team meeting our sprint goal?
o Do I see any impediment that could prevent me or the team from meeting our sprint
goal?
Any impediment (e.g., stumbling block, risk, issue, delayed dependency, assumption proved
unfounded)[31] identified in the daily scrum should be captured by the scrum master and
displayed on the team's scrum board or on a shared risk board, with an agreed person
designated to working toward a resolution (outside of the daily scrum). No detailed discussions
should happen during the daily scrum.

12. Story point

Story points are a unit of measure for expressing an estimate of the overall effort that will be
required to fully implement a product backlog item or any other piece of work.

When we estimate with story points, we assign a point value to each item. The raw values we
assign are unimportant. What matters are the relative values. A story that is assigned a 2 should
be twice as much as a story that is assigned a 1. It should also be two-thirds of a story that is
estimated as 3 story points.
Instead of assigning 1, 2 and 3, that team could instead have assigned 100, 200 and 300. Or 1
million, 2 million and 3 million. It is the ratios that matter, not the actual numbers.

What Goes Into a Story Point?

Because story points represent the effort to develop a story, a team’s estimate must include
everything that can affect the effort. That could include:

 The amount of work to do

 The complexity of the work
 Any risk or uncertainty in doing the work

When estimating with story points, be sure to consider each of these factors. Let’s see how
each impacts the effort estimate given by story points.

13. Epic user story

An epic is a large user story that cannot be delivered as defined within a single iterationor is large
enough that it can be split into smaller user stories.
There is no standard form to represent epics. Some teams use the familiar user story formats (As
A, I want, So That or In Order To, As A, I want) while other teams represent the epics with a short
phrase.

Expected Benefits
Epics allow you to keep track of large, loosely defined ideas in your backlog without the need to
overpopulate your backlog with multiple items. You can remember a vague idea with one backlog
item until your team identifies the need to deliver the outcome that the epic enables. At that point
your team can split the epic into smaller user stories during backlog refinement.
Epics allow you a way to establish a hierarchy for your backlog items where the Epic represents the
original idea often closely related to a particular outcome. The user stories associated with that
epic represent the various aspects of the solution you need to deliver, or the options you have for
satisfying that need.
You may also see the concept of themes used for grouping user stories dealing with the same
topic. The theme concept is frequently used to group user stories that were identified separately
together and can be used as a decision filter of sorts to decide what stories to group into a
particular sprint or delivery. Themes are typically not used as a level in a backlog hierarchy.
Common Pitfalls
Teams can over complicate their use of epics by viewing them as more than just large user stories.
This is apparent when the team creates complex mechanisms to differentiate between epics and
user stories (and potentially other backlog hierarchies) as well as creates extensive tools for
tracking epics separately from other backlog items.
Both of these actions result in wasted effort in the form of whether something is an epic or a user
story and time spent tracking information about a backlog item that is intended to be a
placeholder for future discussions that will result in more finely grained backlog items.
Teams may also try to estimate epics even though these items typically are very vague in nature
and prone to a great deal of uncertainty, reducing the likelihood of reliable or useful estimates.

When Applicable
The concept of epics is particularly useful when you are following a framework such as Scrum that
has explicit timeboxed iterations (ie sprints). Since you organize your work into 2 - 4 week sprints,
you may find a placeholder that represents work that cannot be finished within that time frame
helpful.
Epics are also useful when there is value in having a simple hierarchy in your product backlog.

14. Spike

A time-boxed period used to research a concept or create a simple prototype. Spikes can either
be planned to take place in between sprints or, for larger teams, a spike might be accepted as
one of many sprint delivery objectives. Spikes are often introduced before the delivery of large
or complex product backlog items in order to secure budget, expand knowledge, or produce a
proof of concept. The duration and objective(s) of a spike is agreed between product owner
and development team before the start. Unlike sprint commitments, spikes may or may not
deliver tangible, shippable, valuable functionality. For example, the objective of a spike might
be to successfully reach a decision on a course of action. The spike is over when the time is up,
not necessarily when the objective has been delivered.

15. Product owner(refer scrum qn)

16. Scrum master(refer scrum qn)
17. Define product backlog? Why product backlog grooming and refinement is
necessary(refer scrum qn)
18. Explain product backlog and sprint backlog(scrum qn)

Unit 3

1. Explain relationship between refactoring and test driven development

2. Risk based testing
 3. Explain exploratory testing
4. Explain refactoring with suitable example
5. X unit framework
6. Explain the importance of regression testing in agile
7. What is TDD? Explain its steps with suitable diagram
8. What is acceptance test? Explain any one tool to support agile tester

Section B

Unit 4

1. What are the SOLID principles? Explain OCP with suitable example
2. What is the role of design principles in agile? Explain with open closed
principle
3. Explain single responsibility design principles
4. Explain the symptoms of bad software design write the statement of single
responsibility and interface segregation principle
5. Explain interface segregation principle
6. Explain Liskov substitution design principle with suitable example
7. Explain why agile design practices important

Unit 5

1. Explain dependency inversion principle with suitable examples

2. Explain process of continuous integration with suitable diagram
3. What is version control? Explain its significance in agile software
development. Explain remote and distributed version control system
4. Explain relation between continuous integration and version control

Unit 6

1. How agility is balanced with discipline

2. Explain the need and significance of refactoring
3. Explain refactoring and any 5 refactoring techniques
4. Explain any automated build tool
5. Explain the issues while adopting agile in industry & What are business
benefits of agile methodology
6. What is meant by agile distributed team? Explain the roles in an agile project
7. Write a note on agile projects on cloud
8. Explain how agile and cloud computing practices complement each other
9. Explain the challenges in agile
10. Write a note on agile ALM
11. Explain why agile can work well unit distributed teams OR Explain role of
agile in distributed team
12. What are the practical challenges which constraints the use of agile
methodology
13. How can cloud computing enhance agile software development
14. Justify how agile in distributed teams can prove more successful than current
software development methodology
15. Explain different roles in agile project