PMI- ACP Exam Flash Card

This study aid is prepared with reference books suggested by PMI in line with PMI-ACP
preparation. Topics are aligned and compiled under name of each book to ease reading of
the user. This study aid can be used for CSP exam by Scrum Alliance as well.
 The art of agile development
XP values are courage, communication, simplicity, feedback and respect

Second factor syndrome: In XP, the team who first adopts XP is very successful. But the
second wave of XP projects in organization struggles. Every team needs support when it adopts
XP

Mindfulness: The ability to accept the change effectively

Technical debt: The amount of less than perfect design and implementation decision

Reducing technical debt would increase the velocity of the team

User stories are first introduced in XP

XP can not be applied if development happens in phases instead iterations

The purpose of etude is to practice mindfulness

XP teams support the quest for simple design by finding a metaphor that can be used for the
whole system. The metaphor provides a frame of reference for how they think about the system

XP recommends incremental releases, pair programming, test driven development

2 onsite customers for 3 programmers 2:3, 1 tester for 4 programmers or to 6 programmers 1:4
or 1:6. Needs Programmer coach and Project manager

XP suggests 12 member team: 6 programmers + 4 customers + 1 programmer coach + 1 PM

XP emphasises exploratory testing rather doing customer acceptance testing

Release retrospective, process retrospective, surprise retrospective are the other types of
retrospectives can be conducted.

Mute mapping is a variant of affinity diagram mapping where no team member speaks and
may last for 10 minutes

Prime directive means never use retrospective to blame or attack other individuals

Trust is essential for the team to thrive.

Sitting together leads to fast, accurate communication.
Real customer involvement helps the team understand what to build.
A ubiquitous language helps team members understand each other.
 Stand-up meetings keep team members informed.
Coding standards provide a template for seamlessly joining the teams work together.
Iteration demos keep the teams efforts aligned with stakeholder goals.
Reporting helps reassure the organization that the team is working well

Vertical market software development specific to particular industry and often customized
for each customer
Horizontal market software can be used for wide range of industries

When the whole team uses the ubiquitous language while sitting together, everyone can
overhear domain discussions, especially during pairing sessions

Things to be discussed in daily stand up meeting 1) what did I do yesterday? 2) What will I do
today? 3) What are problems preventing our progress?

Purpose of daily stand up is to achieve brevity that is quality expressing things in short

Creating a coding standard is an exercise in building consensus. It may be one of the first
things that programmers do as a team.

An XP team produces working software every week, starting with the very first week. The
iteration demo is a powerful way to do so. First, its a concrete demonstration of the teams
progress. The team is proud to show off its work, and stakeholders are happy to see progress.

A burn-up chart is an excellent way to get a birds-eye view of the project. It shows
progress and predicts a completion date. Most teams produce a burn-up chart when they update
their release plan.

Roadmap summarizes planned releases and significant features in each one

Throughput is the number of features the team can develop in a particular amount of time

Progress reports to consider: Roadmap, status email

Management reports to consider: Productivity, throughput, defects and time usage
Reports to avoid: Sources line of code and functional points, number of stories, velocity, and
code quality

done done ensures that completed work is ready to release.

No bugs allow you to release your software without a separate testing phase.
Version control allows team members to work together without stepping on each others
toes.
A ten-minute build builds a tested release package in less than 10 minutes.
Continuous integration prevents a long, risky integration phase.
Collective code ownership allows the team to solve problems no matter where they may lie.

Reduce technical debt to reduce bugs in releases

Zero bugs can be achieved by 1)write fewer bugs 2)eliminate by bug breeding grounds 3)fix
bugs quickly 4)test your process 5)fix your process
Following are version control terminologies: Version control helps our code to be kept in an
authoritative place
Repository
The repository is the master storage for all your files and their history. Its typically stored on
the version control server. Each standalone project should have its own repository.

Sandbox
Also known as a working copy, a sandbox is what team members work out of on their local
development machines. (Dont ever put a sandbox on a shared drive. If other people want to
develop, they can make their own sandbox.) The sandbox contains a copy of all the files in the
repository from a particular point in time.

Check out
To create a sandbox, check out a copy of the repository. In some version control systems, this
term means update and lock.

Update
Update your sandbox to get the latest changes from the repository. You can also update to a
particular point in the past.

Lock
A lock prevents anybody from editing a file but you.

Check in or commit
Check in the files in your sandbox to save them into the repository

Revert sandbox to the point of your last update

Revert your sandbox to throw away your changes and return to the point of your last update.
This is handy when youve broken your local build and cant figure out how to get it working
again. Sometimes reverting is faster than debugging, especially if you have checked in recently.

Tip or head
The tip or head of the repository contains the latest changes that have been checked in. When
you update your sandbox, you get the files at the tip. (This changes somewhat when you use
branches.)

Tag or label
A tag or label marks a particular time in the history of the repository, allowing you to easily
access it again.

Roll back remove recently check in code of repository from tip

Roll back a check-in to remove it from the tip of the repository. The mechanism for doing so
varies depending on the version control system you use.

Branch
A branch occurs when you split the repository into distinct alternate histories, a process
known as branching. All the files exist in each branch, and you can edit files in one branch
independently of all other branches.
Merge
A merge is the process of combining multiple changes and resolving any conflicts. If two
programmers change a file separately and both check it in, the second programmer will need to
merge in the first persons changes.

Collective ownership cannot be achieved if files are locked for editing others. Concurrent
editing can be followed which enables two person can edit simultaneously and version control
system merges both the changes done.

Always check in the code that builds and passes all the tests

Duplicating code base will reduce our ability to deliver the code

Automating the builds is one of the easiest ways to improve productivity

Maximum time taken for creating code build is 10 minutes or less than that. Slow tests on
build may lead to delay in build creation

The ultimate goal of continuous integration is to be able to deploy all but the last few hours of
work at any time.

Continuous integration can be practiced by 1)integrate your code every few hours 2)keep
your build and other release infrastructure up to date

Collective code ownership spreads responsibility for maintaining the code to all the
programmers. Everyone shares responsibility for the quality of the code. No single person
claims ownership over any part of the system, and anyone can make any necessary changes
anywhere.

Knowledge silo one or two people can understand the code not all- can not achieve collective
code ownership in this case

XP may use work in progress documentation, produce documentation, handoff

documentation

Vision reveals where the project is going and why its going there.
Release Planning provides a roadmap for reaching your destination.
The Planning Game combines the expertise of the whole team to create achievable plans.
Risk Management allows the team to make and meet long-term commitments.
Iteration Planning provides structure to the teams daily activities.
Slack allows the team to reliably deliver results every iterations
Stories form the line items in the teams plan.
Estimating enables the team to predict how long its work will take.

Vision we know why our work is important and how we will be successful - The vision
statement documents three things: what the project should accomplish, why it is valuable and
the projects success criteria.

The last responsible moment is the last moment at which you can responsibly make a
decision
Planning requires participation from programmers and customers and testers do not have
any explicit role in this game. In this game, programmers for estimating to complete a story and
customers for prioritizing the story

Transition indicator tells when the risk will come true

Mitigation activities reduce the impact of the risk
Contingency activities reduce the impact of the risk, but they are necessary only risk occurs
Risk exposure how much time or money you should set aside to contain the risk

Iteration schedule
Demonstrate previous iteration (up to half an hour)
Hold retrospective on previous iteration (one hour)
Plan iteration (half an hour to four hours)
Commit to delivering stories (five minutes)
Develop stories (remainder of iteration)
Prepare release (less than 10 minutes)

Commitment is a bold statement. It means that youre making a promise to your team and to
stakeholders to deliver all the stories in the iteration plan. It means that you think the plan is
achievable and that you take responsibility, as part of the team, for delivering the stories.

Iteration length can be of any length. Preferably 1 week to any length

Slack we deliver our iteration commitments. Paying down technical debt will increase teams
productivity. Introducing some buffer to meet committed things for iterations

Use index cards to get response from stakeholders and it is much effective than computerized
tools

Stories need to be customer-centric. Write them from the on-site customers point of view,
and make sure they provide something that customers care about. On-site customers are in
charge of priorities in the planning game, so if a story has no customer value, your customers
wontand shouldntinclude it in the plan.

Performance, scalability, and stabilityso-called non functional requirementsshould be

scheduled with stories, too.

Programmers will often use a spike solution to research the technology, so these sorts of stories
are typically called spike stories.

All the programmers should participate in estimating. At least one customer should be present
to answer questions. Once the programmers have all the information they need, one
programmer will suggest an estimate.

How to improve velocity: 1)Pay down technical debt 2) improve customer involvement
3)support energized work 4)offload programmer duties 5)provide needed resources 6)add
programmers
 Incremental Requirements allows the team to get started while customers work out
requirements details.
Customer Tests help communicate tricky domain rules.
Test-Driven Development allows programmers to be confident that their code does what
they think it should.
Refactoring enables programmers to improve code quality without changing its existing
behaviour.
Simple Design allows the design to change to support any feature request, no matter how
surprising.
Incremental Design and Architecture allows programmers to work on features in parallel
with technical infrastructure.
Spike Solutions use controlled experiments to provide information.
Performance Optimization uses hard data to drive optimization efforts.
Exploratory Testing enables testers to identify gaps in the teams thought processes.

A spike solution, or spike, is a technical investigation. Its a small experiment to research the
answer to a problem.

Performance user stories: throughput, latency and responsiveness have to considered in

performance related user stories

Throughput- How many operations can be completed in given period of time

Latency- how much delay is acceptable between starting and completing a single operation
Responsiveness- How much delay is acceptable between starting a operation and receiving
feedback about that operation

Exploratory testing enables you to discover emergent behaviour, unexpected side effects,
holes in the implementation (and thus in the automated test coverage), and risks related to
quality attributes that cross story boundaries such as security, performance, and reliability

Charters, observation, notetaking, heuristics are the tools used in exploratory testing

Charters- helps the testing session be more focused

A heuristic is a guide: a technique that aids in your explorations. Boundary testing is an
example of a test heuristic. Experienced testers use a variety of heuristics, gleaned from an
understanding of how software systems work as well as from experience and intuition about
what causes software to break.

Mastering in agile can be done by improve the process, rely on people, eliminate waste,
deliver value, seek technical excellence

Simplicity is the art of maximising the work not done

QWAN Quality without a name
Dont repeat yourself is to avoid copy and pasting your own code

A good software design minimizes the time required to create, modify, and maintain the
software while achieving acceptable runtime performance.
 Estimating and Planning by Mike Cohn
Velocity: measure of teams rate of progress. Number of story points can be delivered by team
for a sprint

Elapsed time: The amount of time that passes on the clock to do something

Ideal time: time taken to complete a task without considering interruptions

Deriving an estimate for a user story: Expert opinion, analogy, disaggregation

Disaggregation: break into pieces which is easier to estimate

Planning poker: combines Expert opinion, analogy and disaggregation. Team comprises all
the people including programmers, testers, engineers and UI designers. Product owner or
analyst can be the moderator

Burn down chart: shows amount of work or stories remaining at specified point of time in
sprint and shows how team progresses towards goal

Becoming Agile
Scrum also has some weaknesses:
Scrum doesnt want specialists. It may be difficult to quickly convert an existing team from a
group of specialists to a group where anyone can perform any task.
A Scrum team cant be successful without a strong Scrum Master, which makes the process
highly dependent on one individual.
Because Scrum is mainly a framework; the team still needs to identify the practices and
methods to use within the framework.

Some of the characteristics of XP are as follows:

Specific practice Unlike Scrum, XP is specific about the practices that should be
used during a software project. These practices include pair programming, TDD, continuous
integration, refactoring, and collective code ownership.
Modelling XP teams frequently uses modelling to better understand the tasks and
architecture needed to support a user story.
Simplicity Teams perform the minimum work needed to meet requirements.
Automation Unit and functional tests are automated.
Quality through testing Features are tested constantly, and developers check each others
code via pair programming.

These are some of XPs strengths:

Customer-focused (its all about user stories)
Quality via frequent testing
Constant focus on identifying and delivering the critical user stories
High visibility on project status
 Great support for volatile requirements

It also has weaknesses:

Need for team maturity Practices such as pair programming and TDD require responsible
developers, and they arent always easy to obtain.
Dependency on testing If developers know that significant testing will take place
downstream, they may be less than diligent when theyre creating designs.
Scalability XP may not work well for large projects.
Dependency on team member co-location The team usually has a team room.

Roadblocks to become agile:

Lack of agile knowledge
Large project teams
Distributed development team
Fixed bid contract work
An immature or one time team
Going too fast
Team with specialized skill sets
Avoiding customization

Reducing the risk of agile adoption by following assessments: management style, manager
buy in, developer buy in, power distance

Dr.Agile dragile.com is an online agile assessment tool that helps determining your readiness
for 40 different practices

Why we should pursue agile: 1) if there is no specific methodology for projects 2) your
present methodology is struggling to keep up with volume 3) you customers are not happy

Too much coaching as well as too little coaching is dangerous to become agile

Creating core team: 1) They are not part of management 2) Team comprises of doers who
know ins and outs of the organization 3) Having team members all areas initializes awareness
across the company

Attributes of a good coach:

Find a coach with proven results and references
Dont hire a company; hire a person
Soft skills are critical for a coach
Find someone you already know and trust
Consultant should evaluate the organization before committing to any approach
Certification may not be necessary but shows coach dedication to his profession

Agile manager: doing shepherd less directing. Agile manager provides leadership without
using formal power

Soft skills for agile coach: Effective communication, Analytical thinking, diplomacy skill,
great listening skill

Implementation of agile phases: Feasibility, planning, development, adapt, deployment

Agile implementation can be started with pilot project. Following are the characters of pilot
project 1) can complete in 2 to 8 weeks 2) subset of a large project 3) medium priority project
4) project that has all phases and areas 5) no external customers 6) should not be a mission
critical project

Feasibility study has to be completed to select a pilot project, pilot team, creating feature cards,
prioritizing product backlog.

Iteration 0 is the foundational work performed after initial planning but before development
begins. Iteration 0 work usually runs for about a week, but it can take less or more time
depending on project complexity

Exploratory testing is different than functional testing. Functional testing tries to make sure
the software does what its supposed to. Exploratory testing tries to make sure the software
doesnt accidentally do things it isnt supposed to do.

5 categories of adapters as per based on technology adoption life cycle mentioned Geoffrey
Moores book crossing the chasm

Innovators are usually experimentalists who are interested in trying new things. (For 1st pilot
project)
Early adopters willing to take the risk and adopt a new technology because it either
addresses a direct need they have or proposes a new strategic opportunity for them. (2nd wave
of pilot projects)
Early majority pragmatists, conservative, but still open to new ideas if they are convinced.
They usually prefer evolutionary change and are averse to taking risks. (the biggest hurdle)
Late majority Mainstream employees who are less comfortable with technology change and
are usually skeptical. (They need more time until they see more people in organization use new
process)
Laggards May never adopt a new technology. They never adapt to new

Sidky Agile Maturity Model: SAMI has 5 stages. The purpose of the SAMI is to help you
become more agile. The SAMI isnt meant to act as a scoring device.
1. collaboration- enhancing communication and collaboration
2. evolutionary- delivering software early and continuously
3. integrated- developing high quality software in efficient manner
4. adaptive- responding to change through multiple levels of feedback
5. encompassing- establishing environment to sustain agility

Agile project management with scrum

Three legs of the empirical process: visible, inspection, adaption

The heart of scrum lies in iteration. Customer gets incremental product at the end of every
iterations.
Product owner is creating the projects initial overall requirements, return on investment
(ROI) objectives, and release plans

The Team is responsible for developing functionality. Teams are self-managing, self-
organizing, and cross-functional, and they are responsible for figuring out how to turn Product
Backlog into an increment of functionality within iteration and managing their own work to do
so. Team members are collectively responsible for the success of each iteration and of the
project as a whole

The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone
involved in the project, for implementing Scrum so that it fits within an organizations culture
and still delivers the expected benefits, and for ensuring that everyone follows Scrum rules and
practices.

Every sprint is an iteration of 30 consecutive calendar days

Sprint planning has 2 parts and of 8 hours time box. 1st 4 hours product owner explain the
product backlog to team. 2nd 4 hours team plans the sprint backlog
Daily scrum meeting is 15 minutes meeting. Just 3 things will be discussed there. What was
done yesterday? What will you do today? What are the blockers stopping progress?
Sprint review meeting is to explain what was developed in sprint with time box of 4 hours
Sprint retrospective is to analyse what went wrong and right. Time box of 3 hours

The Product Owner is responsible for the contents, prioritization, and availability of the
Product Backlog. The Product Backlog is never complete, and the Product Backlog used in
the project plan is merely an initial estimate of the requirements and evolves as the product and
the environment in which it will be used evolves

The Sprint Backlog is a highly visible, real-time picture of the work that the Team plans to
accomplish during the Sprint.

In scrum pig role is for product owner, ScrumMaster and team who are committed to
projects. Chicken role is for spectators like other managers who are interested in the project

The ScrumMaster is responsible for the success of the project, and he or she helps increase
the probability of success by helping the Product Owner select the most valuable Product
Backlog and by helping the Team turn that backlog into functionality. The ScrumMaster earns
no awards or medals because the ScrumMaster is only a facilitator

The responsibilities of the ScrumMaster can be summarized as follows:

Remove the barriers between development and the Product Owner so that the Product
Owner directly drives development.
Teach the Product Owner how to maximize ROI and meet his or her objectives through
Scrum.
Improve the lives of the development team by facilitating creativity and empowerment.
Improve the productivity of the development team in any way possible.
Improve the engineering practices and tools so that each increment of functionality is
potentially shippable.
Keep information about the teams progress up-to-date and visible to all parties
At the end of the Sprint, the stakeholders attend the Sprint review meetings and compare the
projects actual progress against its planned progress. Changes in course and revisions to the
plan made in Sprint planning meetings are explained to the stakeholders

Scrum projects require less planning than typical Gantt chartbased projects because
those working to deliver the expected benefits provide visibility into their progress at the end of
every Sprint

The minimum plan necessary to start a Scrum project consists of a vision and a Product
Backlog. The vision describes why the project is being undertaken and what the desired end
state is.

The first task is to create the Scrum artefact needed for managing a Scrum project that
product backlog

During sprint, sprint backlog is fixed and can be changed as a result work being performed in
that sprint

The Burndown report graphs remaining estimated workload over the course of the project.
Workload at the start of each Sprint is measured by summing all open Product Backlog work
estimates. From Sprint to Sprint, the increase or decrease in these sums can be used to assess
progress toward completing all work for a release by an expected date.

Scrum works only if everything is kept visible for frequent inspection and adaptation

We accept that the Teams estimate will be imprecise in the first Sprint. Team members
delivering something approximating their commitment in the first Sprint is a testimony to
human pride and determinationnot the Teams estimating accuracy

When more than one Scrum Team works simultaneously on a project, it is referred to as a
scaled project, and the mechanisms employed to coordinate the work of these teams are called
scaling mechanisms

Chickens are not allowed to speak in daily scrum meeting and not to interfere the meeting.
Limiting attendance of too many chickens lie with ScrumMaster responsibility

The purpose of the Sprint review is for the Team to present to the Product Owner and
stakeholders functionality that is done. Although the meaning of done can vary from
organization to organization, it usually means that the functionality is completely engineered
and could be potentially shipped or implemented. If done has another meaning, make sure
that the Product Owner and stakeholders understand it. This is time box of 4 hours

Sprint retrospective meeting has time box of 3 hours and should be attended only by team,
PO and SM. This is to discuss the improvement needed which can be incorporated in
upcoming sprints

Refer page 130 of this book to know the definitions of each roles about scrum
 Software managers bridge to agility
Mapping to agile practices: Integration project management, scope, quality and risk

Integration management: Release and iteration planning, iteration work,

facilitate/serve/lead/collaborate, constant feedback by iteration/demo/retrospective, ranked
backlog

Scope management: Planning meetings, release and iteration plan, feature acceptance,
constant feedback by demo/iteration/review/retrospective, ranked backlog

Feature breakdown structure does not show tasks

An acceptance criterion for each story is written on back of the story card. Passing tests does
not mean acceptance. Every story has to be accepted by product owner

Quality management: test driven development, committed QA resource involved from

beginning, reviews and retrospectives, test early and often, feature acceptance

Risk management: iteration planning/daily stand ups/retrospectives, daily stand ups and
highly visible information radiators

Agile addresses following core risks: Intrinsic schedule flaw, specification breakdown, scope
creep, personnel loss, productivity variation

Servant leader: Facilitate meetings, remove roadblocks, protect team from distractions, help
people communicate, mediate team disputes, negotiate with outside team, provide highly
visible information radiators, and manage external dependencies

Donts:
No need to own product backlog- PO owns
No need to own estimates delivery team does
No need to make delivery decisions you facilitate team for this activity
No need to make product decision PO does this

Lean Agile software development

Manifesto for Agile Software Development
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in development. Agile processes harness change
for the customers competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances Agility.
Simplicitythe art of maximizing the amount of work not doneis essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behaviour accordingly.

The Core Beliefs of Lean

Most errors are due to the system within which people work rather than to the individuals
themselves.
People doing the work are the best ones to understand how to improve the system.
Ad hoc is not an acceptable process.
Looking at when things are done in a process is a more useful guide than trying to make sure
every step of the way is as efficient as possible.
Our measure for success must be related to the amount of time between when ideas come in
and when they are manifested as value to our customers.
Management must work with the team to improve the way it works to improve its own
efficiency.
Teams are most efficient when the amount of work is limited to their capacity.
Team efficiency improves by minimizing the amount of work in progress at any one time.
When evaluating actions, we must optimize the whole, not merely improve individual steps in
the process.
There are principles in software development that must be followed in order to reduce waste.

Release planning in lean software development:

1. Identify features.
2. Prioritize features.
3. Split features using the minimum-marketable-feature perspective.
4. Estimate the value of the features.
5. Estimate the cost of the features.
6. Elaborate further by writing stories for features, repeating until you have reasonable clarity
on what the features are and their high level values.
7. Create a specific release plan by date or by scope.
8. Plan elevations.
 Agile software development a
cooperative game
Two goals of a cooperative game: 1) deliver this software 2) set up for the next game

Good communication is impossible. Equivocality is the ambiguity in communication and

will never be 0. Actions and feedback reduces that to acceptable level.

Programming in pair is more effective

Information radiator: people get information just walk pass by that. Can be used for plans,
status and initiatives

Amicability: willingness to listen with good will. Amicability index explains how quickly
information moves from one part of organization to another. A low amicability index denotes
people blocks the flow of information either by intentionally or not listening well

Peoples learning in 3 stages: SHU-HA-RI

SHU- Following a technique that works
HA- breaking away - Learn limits of the current technique and learn to shift from one to
another
RI- fluency shift techniques by movement

Methodology meets its limit when it meets people

DSDM: rapid application development- developed in UK and managed by DSDM consortium

has 9 core principles
Core practices: business study, prototyping, project management

Feature driven development FDD: it contracts with XP following are key elements of FDD
based on 5 parts with features to be delivered
1) Tight process with exit/entry criteria 2) fix time, cost and scope early 3) chief programmers
with class owners 4) a central model where features are matched to it 5) review domain, review
feature and inspect feature

Adaptive software development: developed by Jim Highsmith practices for large scale
projects introduces an agile management called leadership collaboration

Crystal: Every project is different need its own methodology indexed by colour for the
people only frequent deliveries and post delivery reflection wokshops are mandatory
colours are crystal clear, yellow, orange, red based on 7 principles
User stories applied for agile software
A user story describes functionality that will be valuable to either a user or purchaser of a
system or software. User stories are composed of three aspects:
a written description of the story used for planning and as a reminder
conversations about the story that serve to flesh out the details of the story
tests that convey and document details and that can be used to determine when a story is
complete

Why customer write stories:

The customer team, rather than the developers, writes the user stories for two primary reasons.
First, each story must be written in the language of the business, not in technical jargon, so that
the customer team can prioritize the stories for inclusion into iterations and releases. Second, as
the primary product visionaries, the customer team is in the best position to describe the
behaviour of the product.

The developers have different priorities for many of the stories. They may suggest that the
priority of a story be changed based on its technical risk or because it is complementary to
another story. The customer team listens to their opinions but then prioritizes stories in the
manner that maximizes the value delivered to the organization.

Acceptance testing is the process of verifying that stories were developed such that each
works exactly the way the customer team expected it to work

Every story should have card, conversation and confirmation

Stories should follow INVEST model independent, negotiable, valuable, estimatable, small,
testable

User role modelling steps: These users would use the actual application once stories are
implemented as application/software
1) brainstorm an initial set of user roles 2)organize the initial set 3)consolidate the roles
4)refine the roles

Personas and extreme characters are 2 additional techniques

A persona is an imaginary representation of a user role. The persona is given a name, a face,
and enough relevant details to make them seem real to the project members.

Extreme characters are being used when designing a new system otherwise those stories
would be missed

Developers have to participate in identifying personas and user roles and understanding each
roles of persona

Techniques to create user stories: User interviews, questionnaires, observation, story writing
workshops
User proxies: when real users are not available user proxies can act as real user. Following
people can be as proxies for users 1)users manager 2)development manager 3)salespersons
4)domain experts 5)marketing group 6)former users 7)customers 8)trainers and technical
support 9)business or system analysts

Situations where proxies can be used: 1) when users exist when access is limited 2) when
user is not available

Acceptance tests provide a great deal of information that the programmers can use in advance
of coding the story

Because the software is being written to fulfill a vision held by the customer, the acceptance
tests need to be specified by the customer. The customer can work with a programmer or
tester to actually create the tests and has responsibility to execute acceptance tests

Acceptance tests are meant to demonstrate that an application is acceptable to the

customer who has been responsible for guiding the system's development. Minimally,
acceptance tests should be executed at the end of every iteration. Because working code from
one iteration may be broken by development in a subsequent iteration.

FIT and fitness are the excellent automation tools to cover acceptance test in table or spread
sheet format

A closed story is one that finishes with the achievement of a meaningful goal and that allows
the user to feel she has accomplished something.

Characteristics of a good story:

Write for one user
Should be in active voice say User can post resume
Customer has to write stories
Dont number story cards
Dont forget the purpose

My preferred estimation approach is derived from the Wideband Delphi approach

documented by Boehm. First, gather together the customer and the developers who will
participate in creating the estimates. Bring along the story cards and a stack of additional blank
note cards. (Bring some blank cards even if you're maintaining the story descriptions
electronically.) Distribute a handful of blank cards to each participant. The customer selects a
story at random from the collection and reads it to the developers. The developers ask as many
questions as they need and the customer answers them to the best of her ability. If she doesn't
know the answer, she takes a guess or asks the team to defer estimating that story.

Triangulating an estimate refers to estimating a story based on its relationship to one or more
other stories. Suppose a story is estimated at four story points. A second story is estimated at
two story points. When the two stories are considered together the programmers should agree
that the four-point story is roughly twice the size of the two-point story

Whether or not a team chooses to pair program has no effect on story point estimates. Do
not consider pair programming efforts in calculating story point estimate
DSDM includes a prioritization technique referred to as the MoSCoW rules. MoSCoW is an
acronym for must have, Should have, could have and would not have

Collectively the developers and the customer select an iteration length that will work for them.
Iteration lengths are typically from one to four weeks

So, if the project has 100 story points and we estimate velocity at 20 story points per
iteration, then we can expect it to take 5 iterations.

There are three ways to get an initial value for velocity:

1. Use historical values.
2. Run an initial iteration and use the velocity of that iteration.
3. Take a guess.

The general sequence of activities for an iteration planning meeting is as follows:

1. Discuss a story.
2. Disaggregate the story into its constituent tasks.
3. One developer accepts responsibility for each task.
4. After all stories have been discussed and all tasks have been accepted, developers
individually estimate the tasks they've accepted to make sure they are not over-committed.

The number of story points completed in iteration is known as the project's velocity

Iterative development will not be suitable for front end development. Since browsing time
will lead to poor customer satisfaction

User stories are not use cases, not scenarios; it is different from IEEE software requirements
specifications

Advantages of user stories over alternative approaches:

User stories emphasize verbal communication.
User stories are comprehensible by everyone.
User stories are the right size for planning.
User stories work for iterative development.
User stories encourage deferring detail.
User stories support opportunistic design.
User stories encourage participatory design.
User stories build up tacit knowledge.

Causes on stories when it has following attributes

Stories are too small frequent revisit required for revised estimation
Interdependent stories difficulty in planning iteration because of dependent stories
Gold plating - Developers are adding features that were not planned for the iteration, or are
interpreting stories liberally and going beyond what is necessary to implement a story.
Too many details more time is required to write stories than talking about them
Including user interface details too soon
Thinking too far ahead- hard to fit on note cards
Splitting too many stories
Customer has trouble prioritizing and wont write stories
An iterative process is one that makes progress through successive refinement. An
incremental process is one in which software is built and delivered in pieces.

Nonfunctional requirements (such as for performance, accuracy, portability, reusability,

maintainability, interoperability, capacity and so on) can often be handled by creating
constraint cards. If the system has requirements that are more complex than this,
supplement your user story approach with whatever additional format or technique best
expresses those requirements.
Neither note cards nor a software system is the best way to write stories in all cases.
Match the tool to the project and team.
An iterative process can lead to iterative changes in the user interface. Users, who
become accustomed to very specific aspects of the interface, do not like user interface
changes that affect how they have learned to operate the software. Consider adding
some practices from Agile Usage-Centered Design to avoid iterating the user interface.
There's a certain joy in ripping up a story card as soon as it's complete. But there are
also reasons to retain the cards. Err on the safe side and retain the stories.
Staple small bug reports together with a cover story card and treat them as a single
story.

Refer question and answer for this book from page 325

Kanban
The basic principles of Kanban for software engineering
Limit work in progress (WIP)
Pull value through (with WIP limit)
Make it visible
Increase throughput
Fixed Kanban backlog
Quality is embedded in (not inspected in)

Lead time Clock starts when request is made and ends when it is delivered.
Cycle time- starts when actual work begins and ends at when work is delivered. Cycle time is
the more mechanical measure of process capability

Total cycle time- = no of things in progress / average completion rate

How to improve cycle time: 1) reduce number of things in process 2) improve average
completion rate 3) reduce rework 4) high visibility of blockers and active removal 5) analysis
to identify items that are too large

Throughput is the rate of delivery of customer valued work into production

Kanban allows for specialization but not enforcing it

Kanban projects can have 40 people or more. Kanban pull system is more focused on work
and work flow than first generation agile processes
 Wastes in software engineering: rework or defects, coordination cost and transaction cost

MMF creates value is following ways: competitive differentiation, revenue generation, cost
saving, brand projection, enhanced loyalty

Agile is sometimes called light weight method since they are less prescriptive than traditional
methods

Books Referred
Agile project management with scrum
Becoming agile
Agile project development a cooperative game
Estimating and planning by Mike Cohn
Lean agile software development
The Software manager bridges to agility
The Art of agile development
User stories applied