1. Agile Manifesto
In 2001, a group of 17 programmers who work in IT Programming and interested in Iterative and agile
methods met in Snowbird, UT to develop common framework for what is meant by Agile methods. This group
has created the Agile Manifesto.
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Items on left are considered value drivers while the items on right are generally management controls for
software development. Many members consider that Agile is a project management approach rooted in
programming parlance while traditional waterfall approaches (PMP) are rooted in management parlance.
Agile Principles
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.
www.StarPMO.com
Agile Team Roles
1. Programmers, designers, architects: How to design and program the software

2. 2. Product managers: Why the software is important
3. Domain experts (SME): The rules to be followed by software. Must follow industry standards like
regulatory etc.
4. Interaction designers: How the software should behave (Understand users, needs, how they interact
with software etc)
5. Graphic designers: How should user interface look like
6. Tester: Where are defects likely to be found
7. Project manager: How to interact with rest of the company (read Politics)
In many ways, the traditional project roles still exist in an Agile project, but in a modified manner for a
modified purpose.
www.StarPMO.com
Agile Artifacts
An artifact is a document or a chart to manage an Agile project
1. Sprint burn down chart: The sprint burn down chart is a publicly displayed chart showing remaining
work in the sprint backlog as the spring progresses.
2. Product backlog: The product backlog is a high-level list that is maintained throughout the entire
project. It aggregates backlog items: broad descriptions of all potential features, prioritized as an
absolute ordering by business value based on various metrics to be determined by the project team
(For example provided by www.unleashpm.com). It is therefore the “What” that will be built, sorted by
importance. It is open and editable by anyone and contains rough estimates of both business value and
development effort. Those estimates help the Product Owner to gauge the timelines and, to a limited
extent prioritize. The Product Backlog, and business value of each listed item is the property of the
product owner. The associated development effort is however set by the Team.
3. Sprint backlog: The sprint backlog is the list of work the team must address during the next sprint.
Features are broken down into tasks, which, as a best practice, must be 4-8 in any given sprint. With
this level of detail the whole team understands exactly what to do, and potentially, anyone can pick a
task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the
team members as needed, according to the set priority and the team member skills. This promotes
self-organization of the team, and developer buy-in. The sprint backlog is the property of the team,
and all included estimates are provided by the Team. Often an accompanying task board (For example
provided by www.unleashpm.com) is used to see and change the state of the tasks of the current
sprint, like “to do”, “in progress” and “done”.
www.StarPMO.com
Daily Agile Meeting or Stand up Meeting
On each day of a sprint, the team holds daily meetings in a stand up position for about 10 minutes
(“the daily Agile meeting or a stand up meeting”). Meetings are typically held in the same location and
at the same time each day. Ideally the daily Agile meetings are held in the morning as they help set the
context for the day's work. All team members are required to attend the daily scrum but will not be
postponed if someone is not in a position to attend. Since both the Project Manager and Product

3. Owner are committed team members, they are expected to attend and participate. Anyone else (for
example, Head of the department, a salesperson, or a developer from another project) is allowed to
attend but are there only to listen. This makes the daily Agile an excellent way for an Agile team to
disseminate status information--if you're interested in hearing where things are at, attend that day's
meeting.
The daily stand up meeting is not used as a problem-solving or issue resolution meeting. Issues that are
raised are taken offline and usually dealt with by the relevant sub-group immediately after the
meeting. During the stand up each team member provides answers to the following three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?
By focusing on what each person accomplished yesterday and will accomplish today the team gains an
excellent understanding of what work has been done and what work remains. The stand up meeting is
not a status update meeting in which a boss is collecting information about who is behind schedule.
Rather, it is a meeting in which team members make commitments to each other. If a programmer
stands up and says "Today I will finish the user information generation template" everyone knows that
in tomorrow's meeting he will say whether or not he did finish. This has the wonderful effect of helping
a team realize the significance of these commitments and that their commitments are to each other,
not to some distant customer.
Any impediments that are raised become the Project Manager’s responsibility to resolve as quickly as
possible. Typical impediments are:
• I still haven't got the upgrade I ordered a month ago.
• I need help debugging a problem with ______.
• I'm struggling to learn ______ and would like to pair with someone on it.
• The department Head has asked me to work on something else "for two days”.
In cases where the project manager cannot remove these impediments directly himself (e.g., usually
the more technical issues) he still takes responsibility for making sure someone on the team does
quickly resolve the issue.
www.StarPMO.com
Technical Debt
It is the total amount of “less than perfect” design and implementation decisions in the project. Quick and
dirty hacks made to make something work right now. This usually increases the maintenance cost and cost of
adding new features. Refactoring is done to reduce technical debt so that code can be reused. Technical debt
is something which prevents team from being Agile and has to be constantly addressed as the project
progresses.
www.StarPMO.com
Time boxing
Work invariably stretches to use the existing time (Student syndrome). Time boxing prevents this by ensuring
a work stops when it is time up. It will prevent “ Analysis paralysis”.
www.StarPMO.com

4. Last responsible moment
Making decisions during the moment at which failing to make a decision eliminates an important alternative. If
you delay beyond this time decisions are made by default which is NOT good. By delaying the decision till this
point you improve accuracy of decisions, decrease your workload and decrease impact of changes. All this
because you will have higher information at the time of decision making.
www.StarPMO.com
Use Stories
They Represent a self contained, individual elements of work. They correspond to individual features and
represent one or two days of work.
E.g. A Job application portal: “Ability to search for a job” is a story.
www.StarPMO.com
Iterations or Sprints
Iteration or a Sprint is the full cycle of design-code-verify-release of an Agile team. Each iteration will involve
customer deciding what stories to implement in the iteration and results in an software which the customer
can use. Beginning of an iteration i where the customer can make changes to the direction of software
development. Although planning is frequent, it is small and proportion to the size of iterations.
www.StarPMO.com
Velocity
A measure to be able to determine the amount of work which can be done in an iteration. Most common
ways to express velocity are user story points or man days.
www.StarPMO.com
Theory of constraints
Every system has a single constraint that determines the overall throughput of the system. One must find the
constraints in the system (developers, programmers, testers) and eliminate the constraint.
www.StarPMO.com
Mindfulness
The ability to respond effectively to changes requires that everyone pay attention to the process and practices
of development and this is called “mindfulness”. Sometimes there are subtle pending changes, you may
realize technical debt to be growing or the tone of customer feedback to be changing, or team behavior
changing etc.
www.StarPMO.com
Pair programming
Two members share the same keyboard. One member does the coding (and the tactical issues concerned) and
the other members think about the big picture (Driver and a navigator). The partners can switch when
frustrated or stuck. This usually gets people tired more than solo programming as the energy involved is
higher. A good rule of thumb is to pair up anything which needs maintenance. Large monitors and good leg

5. room is essential. Create chances for both the members to be learning to enhance the utility of pair
programming.
www.StarPMO.com
Energized work
When you are energized you work better. One of the best ways to feel energized is to take care of yourself. Go
home on time every day, spend time with family & friends and do engage in activities that take your mind off
of work. At work, give full attention to work. Turn off interruptions like e-mail, instant messages, phones and
shield from unnecessary meetings. If you make more mistakes than progress, then it is time to take a break.
www.StarPMO.com
Informative work space
An informative work space brings information into the team. It allows the team to sense the state of project
when they take breaks. An informative work space also provides for people to communicate easily.
Big visible charts and hand drawn charts are preferred.
www.StarPMO.com
Root cause analysis
Everybody makes mistakes- Aggressively laying blame does not solve this problem and only causes people to
hide the mistakes.
Instead of thinking of this as a people issue, think of it as a process issue- This is called as root cause analysis.
5 Why technique is a good tool for root cause analysis.
Fixing root causes needs the cooperation of other people and this can be done by during retrospectives.
1. Example: Why is our largest customer unhappy? Because our deliveries of bicycles have been late for
the last month.
2. Why have our bicycle deliveries been late for the last month? Because production has been behind
schedule.
3. Why has production been behind schedule? Because there is a shortage of wheels.
4. Why are we having a shortage of wheels? Because incoming inspection has rejected a large number of
wheels for not being round.
5. Why are we rejecting so many parts? Because purchasing switched to a cheaper wheel supplier that
has inconsistent quality.
www.StarPMO.com
Retrospectives
Retrospectives (Introspective lessons learned meetings) are a great way to continually improve a process.
Iteration retrospective happens at the end of each retrospective. Following are a few tools to keep in mind in a
retrospective.
• Prime directive: No blame game.
• Brainstorming (Enjoyable, frustrating, puzzling, same, more ,less): Use of index cards
• Mute mapping (Variant of Affinity mapping)

6. • Pick the one with highest number of cards and focus on it (discard others for this retrospective). Can
use root cause analysis.
www.StarPMO.com
Trust
Trust is essential for a team to improve productivity. Some strategies to create trust:
• Customer programmer empathy: Sitting together and understanding different point of view.
• Programmer-tester empathy
• Eat together
• Team continuity
• Impressions (Organizational antibodies)
www.StarPMO.com
Ubiquitous Language
Will help reduce mistakes and greatly increase communication. It is suggested that programmers should speak
the language of domain experts and not other way around. The code can use functions, classes etc based on
the domain experts language.
www.StarPMO.com
Coding standards
Creating of coding standards will help increase communication and collaborative work.
Not just formatting, but naming the variables, handling exceptions, when and where to log events etc are all
part of standardization.
www.StarPMO.com
Iteration Demo
It’s a concrete way to show your progress and keep stakeholders happy. It helps the team to be honest about
their progress and helps solicit feedback from the customers and change direction if needed. Any one can do
this, but is best done by the product manager.
Two key questions to ask at end of iteration demo are:
1. Is the work satisfactory till date
2. Can the work be continued
www.StarPMO.com
Agile Reporting
Only product reports that are strictly necessary (as reports take up time). There are progress reports and
management reports.
Some practices for progress reports are:
• Weekly demo
• Release and iteration plans
• Burn up chart
• Status e-mails
Some practices for management reports are:

7. • Productivity (The actual metrics are difficult and needs stakeholder involvement)
• Throughput (Number of features developed)
• Defects (Decide who will arbiter defect vs intentional behavior)
• Time usage (Developing, planning, improving skills, out of office, un accounted)
www.StarPMO.com
Version control
Will help team to co-ordinate source code, testing and other artifacts. It provides a central repository for the
code.
Repository: Storage place for all the files.
Sandbox: It is a working copy of files on local system
Check out: To create a sandbox check out a copy of repository (also called as update and lock)
Update: Update sandbox to get latest changes from the repository
Lock: Prevents anyone from making changes except you
Check in or commit: Check in the files from sandbox to save them into repository
Revert: Throw away changes and return to point of last update
Tip or head: Contains the latest changes made to the code that has been checked in
Tag or label: A mark allowing easy access
Roll back: A check in to remove from tip of the repository
Branch: Create distinct “Alternate histories”
Merge: Merge multiple files and resolve conflicts
Concurrent Editing: Where multiple users can edit at same time and if two users edit same line of code then
the lines are prompted to be merged manually.
Collective code ownership is encouraged for Agile software development approach.
www.StarPMO.com
Continuous Integration
Get members to agree to build frequently and never break the build. Agreement is the key as forcing is not
likely to work. The general rule to keep the build to under less than 10 minutes. If the build is reasonably fast,
the it is a good idea to do synchronous integration (Confirm that the build and test succeeded before you go
to next step). If the build takes longer, then it is tantalizing to do asynchronous integration. The biggest
problem is that it tends to result in broken builds and you have to interrupt your work later when the build
breaks. If anyone has checked out the code in the mean time their build will not work either (If they have gone
out for lunch then someone else has to fix the mess).
www.StarPMO.com
Osmotic Communication
Communication that is picked up or absorbed by another person. Osmotic communication means that
information flows into the background hearing of members of the team, so that they pick up relevant
information as though by osmosis. This is normally accomplished by seating them in the same room. Then,
when one person asks a question, others in the room can either tune in or tune out, contributing to the
discussion or continuing with their work. When osmotic communication is in place, questions and answers
flow naturally and with surprisingly little disturbance among the team. Osmotic communication is the more

8. powerful version that small projects can attain of close communication, a property core to the entire Crystal
family. Osmotic communication makes the cost of communications low and the feedback rate high, so that
errors are corrected extremely quickly and knowledge is disseminated quickly.
People learn the project priorities and who holds what information. They pick up new programming, design,
testing, and tool handling tricks. They catch and correct small errors before they grow into larger ones.
Although osmotic communication is valuable for larger projects, it is, of course, increasingly difficult to attain
as the team size grows. Hence it is suggested in Agile methods that if the need for growing the size of team is
felt, better thing to do is to recruit the team with higher experience. It is hard to simulate osmotic
communication without having the people in the same room; however, adjacent rooms with two or three
people in each confers many of the benefits.
www.StarPMO.com
Communication Factors
There are several factors that effect communication, including:
1. Physical proximity. The closer people are to one another the greater the opportunities for
communication.
2. Temporal proximity. Whether or not two people are working at the same time affects
communication.
3. Amicability. Amicability, the willingness of someone to hear the thoughts of another person with good
will and to speak without malice, is an important success factor. The greater the amicability a greater
amount and quality of information will be communicated and less will be concealed. Amicability is
closely followed by the trust that people have for one another and the sense of community that they
share. Sometimes amicability can run too high, people can be so worried about offending their
colleagues that they are afraid to disagree with them or be afraid to take the initiative for fear of being
perceived as glory seekers.
www.StarPMO.com
Kanban Board
A Kanban System visualizes some unit of value. This unit of value could be a User Story, Minimal Marketable
Feature, Plain Old Requirement or something else. This is different from a task-board, which generally focuses
on visualizing the current tasks.
A Kanban System manages the flow of these units of value, through the use of “Work In Process limits”. This is
different from a task-board, which generally has no WIP limits, but aims to have all tasks complete by the end
of a time-box. A Kanban System deals with these units of value through the whole system, from when they
enter a teams control, until when they leave it. This is different from a task-board, which generally only deals
with the work in the build/test stage, but shows no information about what work is being prepared, or what
work is ready for release.

9. By putting these 3 properties of a Kanban System together, we can describe a Kanban System for Software
Development as one which allows value to flow through the whole system using WIP limits to create a
sustainable pipeline of work. Further, the WIP Limits provide a mechanism for the Kanban System to
demonstrate when there is capacity for new work to be added, thereby creating a Pull System. Finally, the WIP
Limits can be adjusted and their effect measured as the Kanban System is continuously improved.
A task-board simply shows what development tasks have been predicted to be done in the current time-box,
with their status.
www.StarPMO.com
Agile Iteration Planning
After the iteration demo and retrospective are complete, iteration planning begins. Start by measuring the
velocity of the previous iteration. Take all of the stories that are "done done" and add up their original
estimates. This number is the amount of story points you can reasonably expect to complete in the upcoming
iteration.
Be sure to use estimated time, not actual time, when calculating velocity. This allows the velocity to account
for interruptions and other overhead. With your velocity in hand, you can select the stories to work on this
iteration. Ask your customers to select the most important stories from the release plan. Select stories that
exactly add up to the team's velocity. You may need to split stories or include one or two less important
stories to make the estimates add up perfectly.
Because the iteration planning meeting takes stories from the front of the release plan, you should have
already estimated and prioritized those stories. As a result, selecting stories for the iteration plan should only
take a few minutes, with perhaps ten or 15 minutes more to explain.
www.StarPMO.com
Size Estimation: Story Points
Points is a relative measure that can be used for agile estimation of size. The team decides how big a point is,
and based on that size, determines how many points each work item is. To make estimation go fast, use only
full points, 1, 2, 3, 5, 8, and so on. To get started, look at 10 or so representative work items, give the smallest
the size of one point, and then go through all other work items and give them a relative point estimate based
on that point. Note that points are used for high-level estimates, so do not spend too much time on any one
item. This is especially true for work items of lower priority, to avoid wasting effort on things that are unlikely
to be addressed within the current iteration.
Use non linear number sequence (Like Fibonacci numbers) to determine size as humans can differentiate non-
linear numbers better than linear number sequences.
A key benefit of points is that they are neutral and relative. There may be disagreement about the actual
effort required to do it, but we do not care at this point in time, we only want the team to agree on the

10. relative size. We will later use Velocity to determine how much 'size', or how many points, the team can take
on within an iteration.
www.StarPMO.com
Spike Solution
It is a technical investigation or experiment to research the answer to a problem (For example, you want to
know if C# throws an exception on floating point overflow, you can do a quick spike to find the answer)
The biggest problem with Spike solution is that it takes time to experiment which is going to be wasted after
the solution is found. A Spike Solution:
1) Is an experimental solution that cuts through all the "layers.“
2) Is necessarily time-boxed.
3) Is always intended to be thrown away.
Spike – a spike is a quick and dirty implementation to show that the suggested solution would work. It does
not follow the laid down architecture and might be done in a different language all together. For example a
spike could be done in RoR and then later implemented in Java. These are more like prototypes and are
thrown away.
www.StarPMO.com
Size Estimation: Ideal days
Ideal days are the imaginable amount of time that would be spent on the project if there were no
interruptions (including email checking), everybody was working full time at full speed without any vacations
and everything needed was present from the day one.
Pros:
• The concept of ideal time is relatively simple to explain both to developers and their bosses.
Cons:
• Since both elapsed and ideal times are measured in the same units, they tend to mix
• Not everybody is eager to accept that in a real world week there can be only two-three full ideal work
days
• Since team skills and the understanding of the subject area raise over time, ideal day estimations tend
to decay and have to be readjusted often
• Ideal days can be difficult to sum. My ideal days are not equal to yours
www.StarPMO.com
Agile Exploratory Testing
Exploratory testing is a style of testing in which one learns about the software while simultaneously designing
and executing tests, using feedback from the previous tests to inform the next. This helps discover emergent
behavior, unexpected side effects etc. Four tools are helpful for exploratory testing. They are:
1. Charter: A small document providing information about what to explore and what of things to look for
in the system.
2. Observation: Based on observations of code.
3. Note taking: To prevent where you have been and where you are going, can take the aid of a notepad.
Take notes of what might need further exploration.

11. 4. Heuristics: A guide which helps in explorations (Like boundary testing)
www.StarPMO.com
Iteration Velocity
Velocity is the number of story points completed in an iteration. Ways to increase velocity:
1. Pay down technical debt
2. Improve customer involvement
3. Support energized work
4. Offload programmer other admin duties
5. Provide necessary resources
www.StarPMO.com
Agile Personas
A persona, first introduced by Alan Cooper, defines an archetypical user of a system, an example of the kind of
person who would interact with it. The idea is that if you want to design effective software, then it needs to
be designed for a specific person. For the bank, potential personas could be named Frances Miller and Ross
Williams. In other words, personas represent fictitious people which are based on your knowledge of real
users.
You’re likely familiar with actors. Unlike actors, personas are not roles which people play. In use case modeling
actors represent the roles that users, and even other systems, can take with respect to your system. For
example, in a banking application we would have actors such as Customer and Credit Card Processor. Actors
are often documented by a sentence or two describing the role. For example the description for Customer
might read “A person or organization which does business with the bank.”
Personas are different because they describe an archetypical instance of an actor. In a use case model we
would have a Customer actor, yet with personas we would instead describe several different types of
customers to help bring the idea to life.
www.StarPMO.com
Test Drive Development (TDD)
Test-driven development (TDD) is a software development process that relies on the repetition of a very short
development cycle: first the developer writes a failing automated test case that defines a desired
improvement or new function, then produces code to pass that test and finally refactors the new code to
acceptable standards. A 2005 study found that using TDD meant writing more tests and, in turn, programmers
that wrote more tests tended to be more productive.
Programmers using pure TDD on new ("greenfield") projects report they only rarely feel the need to invoke a
debugger. Used in conjunction with a version control system, when tests fail unexpectedly, reverting the code
to the last version that passed all tests may often be more productive than debugging.
Test-driven development offers more than just simple validation of correctness, but can also drive the design
of a program. By focusing on the test cases first, one must imagine how the functionality will be used by
clients (in the first case, the test cases). So, the programmer is concerned with the interface before the
implementation. This benefit is complementary to Design by Contract as it approaches code through test cases
rather than through mathematical assertions or preconceptions.

12. Test-driven development offers the ability to take small steps when required. It allows a programmer to focus
on the task at hand as the first goal is to make the test pass. Exceptional cases and error handling are not
considered initially, and tests to create these extraneous circumstances are implemented separately. Test-
driven development ensures in this way that all written code is covered by at least one test. This gives the
programming team, and subsequent users, a greater level of confidence in the code.
Test-driven development is difficult to use in situations where full functional tests are required to determine
success or failure. Examples of these are user interfaces, programs that work with databases, and some that
depend on specific network configurations. TDD encourages developers to put the minimum amount of code
into such modules and to maximize the logic that is in testable library code, using fakes and mocks to
represent the outside world.
Management support is essential. Without the entire organization believing that test-driven development is
going to improve the product, management may feel that time spent writing tests is wasted.
www.StarPMO.com
Tracer Bullet
Pragmatic Programmers usually prefer a "Tracer Bullet" which:
1) Is an experimental solution that cuts through all the "layers" of the architecture.
2) Is not necessarily time-boxed.
3) Is not intended to be thrown away.
It is of production quality and rest of the iterations can build on this code.
www.StarPMO.com