rumgileebookasc

Basic Training Material
Agile Scrum Master

Visual Agilexicon
Slides in this presentation contain items from the
Visual Agilexicon, which is a trademark of
Innolution, LLC and Kenneth S. Rubin.
The Visual Agilexicon is used and described in the
book:“Essential Scrum:A Practical Guide to the
Most Popular Agile Process”
You can learn more about theVisual Agilexicon and
permitted uses at:
http://innolution.com/resources/val-home-page
Connect with Innolution:
Connect with Innolution:
Facebook.com/InnolutionLLC
Facebook.com/InnolutionLLC
Twitter.com/krubinAgile
Twitter.com/krubinAgile

Use of visuals
We encourages the use of visuals and diagrams, rather than text in a
presentation.
The visuals included in this material are not ours. They have been obtained via:
http://www.innolution.com/resources/visual-Agilexicon.
To make use of the visuals –and many more- please register your company on
that website. The use of visuals is free of charge after registration.
You may, of course choose to use other visuals. If these are produced by a third
party, please make certain you have the right to use and share them.

Training schedule
• Introduction
• Agile Way of Thinking
• Scrum Master Role
• Agile Estimating, Planning, Monitoring and Control
• Complex Projects
• Adopting Agile

Course Objectives andTarget Audience
Scope
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by
facilitating the Scrum Team in adhering to Scrum theory, practices, and rules.
In order to do this, the Scrum Master role struggles with the apparent contradiction of the Scrum Master as both a
servant-leader to the team and also someone with no authority.The Scrum Master is responsible for maximizing the
throughput of the team and for assisting team members in adopting and using Scrum.A successful Scrum Master
influences others, both on the team and outside it. The Scrum Master helps those outside the Scrum Team
understand which interactions with the Scrum Team are helpful and which aren’t.
Target group
Scrum is the most used Agile methodology. The Agile Scrum Master certification is suitable for all professionals
looking to keep their knowledge up to date with the latest developments in the fields of IT and Project Management,
specifically those participating in or leading projects. In particular, the certification is suitable for professionals
working in an Agile context and who have the ambition to facilitate a Scrum team by assuming the role of a Scrum
Master.

Basic Concepts
• The list of Basic Concepts in the student notes below will be
considered understood for the exam.
• The student is advised to research and understand the
concepts.

Exam Format
Exam details
90 minutes
Computer-based or paper-based multiple-choice questions
Number of questions: 40
Pass mark: 65% (26 out of 40)
Open book, notes, or electronic equipment/aides permitted : No

Exam Literature
A- Succeeding with Agile: Software Development Using Scrum
Mike Cohn - ISBN-13: 9780321579362 or ISBN-10: 0321579364
Addison-Wesley Professional; 1 edition (October 1st , 2009)
B- Agile Estimating and Planning
Mike Cohn - ISBN-13: 9780131479418 or ISBN-10: 0131479415
Prentice Hall; 1 edition (November 11th , 2005)
C-The Scrum Guide™
Ken Schwaber & Jeff Sutherland
Scrum.Org and ScrumInc. (2016)
D- http://www.scaledAgileframework.com/
E- Agile and ITIL and how they integrate
Peter Measey
British Computer Society
The literature references are given in the notes for slides at x.y level.

1.1 Agile Concepts
Scrum
Many
more...
LEAN
XP Agile DEVOPS
Atern CRYSTAL
DSDM

1.1 Agile Concepts
Agile is a word, that means to move fast and easily.
The word Agile is used to make reference to a group of frameworks. Examples of other
frameworks are:
Crystal, DevOps (Development and Operations), Lean, Scrum, XP (Extreme
Programming)...

1.1.1 Explain the Agile way of Thinking

Below we look at the reasons why transitioning to an Agile process is worthwhile:
• Higher productivity and lower costs
• Improved employee engagement and job satisfaction
• Faster time to market
• Higher quality
• Improved stakeholder satisfaction
• What we’ve been doing no longer works

These are some concepts of Agile Development :
I- Iterative
II- Incremental
III- Self organizing teams
IV- Cross-functional teams
V- Users Inspection
VI- MaximizeValue

The Agile Manifesto
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
I- Individuals and interactions over processes and tools
II- Working software over comprehensive documentation
III- Customer collaboration over contract negotiation
IV- 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.

The Principles of the Agile Manifesto
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.

Core Principles of Agile:
• Encourages change
• Shippable product increments
• Receive and give feedback
• Frequent delivery
• Continuous improvement

When the values of commitment, courage, focus, openness and
respect are embodied and lived by the Scrum Team, the Scrum
pillars of transparency, inspection, and adaptation come to life
and build trust for everyone.The Scrum Team members learn
and explore those values as they work with the Scrum events,
roles and artifacts.

To keep your self-organizing team working as a unit instead of a
collection of individuals, you must constantly reenergize and focus it toward shared goals.To do
this you must find ways to renew team members’ commitment to their purpose and to each
other.There are a number of things you can do to build and nurture this kind of commitment.
• Involve widely
• Find an igniting purpose
• Tap into existing intrinsic motivation
• Beware the least motivated team member
• Help everyone understand their relevance to the goal
• Build confidence

1.1.2 Explain how Agility brings Predictability and Flexibility
Five common activities necessary for a successful and
lasting Scrum adoption:
• Awareness that the current process is not delivering
acceptable results
• Desire to adopt Scrum as a way to address current
problems
• Ability to succeed with Scrum
• Promotion of Scrum through sharing experiences so
that we remember and
others can see our successes
• Transfer of the implications of using Scrum
throughout the company
Conveniently, these five activities—Awareness, Desire,
Ability, Promotion, and
Transfer—can be remembered by the acronym ADAPT.

Awareness - Change begins with an awareness that the status quo is no longer desirable.
However, becoming aware that what worked in the past is no longer working can be extremely
difficult.
Common reasons why individuals can be slow to develop an awareness of the need to
change include the following:
• A lack of exposure to the big picture. The need to adopt Scrum may be the
result of a confluence of factors not visible to everyone.The need for a change
may be apparent only to those who have seen the decline in sales to new
customers, heard the rumors of a strong competitor entering the company’s
space, and anticipate the need to do more without adding staff.

Tools for developing Awareness :
• Communicate that there’s a problem
• Use metrics
• Provide exposure to new people and experiences
• Run a pilot project
• Focus attention on the most important reasons to change

Desire - Beyond being aware of the need to change, one must also have the desire to
change. Moving from an awareness that the current development process isn’t working
to the desire to use a different one can be very hard for many people.After all, we’ve
been educated to prefer a sequential approach, both through our schooling and years
of experience. Additionally, although we may be dissatisfied with elements of our
projects, we’ve worked hard to get the right boss and the right team. Scrum would
change all that. Finally, as simple as it may seem, sometimes the timing may just not be
right.
The good news is that the same message delivered the same way but at a different time
will often be enough to move someone along from awareness to desire.

Tools for developing Desire:
• Communicate that there’s a better way
• Create a sense of urgency
• Build momentum
• Get the team to take Scrum for a test drive
• Align incentives (or at least remove disincentives)
• Focus on addressing fear
• Help people let go
• Don’t discredit the past
• Engage employees in the effort

Ability - All of the awareness and desire in the world won’t get a team anywhere if it
does not also acquire the ability to be Agile.
Succeeding with Scrum requires team members not only to learn new skills but also to
unlearn old ones. Some of the larger challenges Scrum teams will face include the
following:
• Learning new technical skills.
• Learning to think and work as a team.
• Learning how to create working software within short timeboxes.

Tools for developing Ability:
• Provide coaching and training.
• Hold individuals accountable.
• Share information.
• Set reasonable targets.
• Just do it.

Promotion - There are three goals during promotion.The first is to lay the
groundwork for the next pass through the ADAPT cycle. By promoting current
successes you will have a jump start on creating awareness for the next round of
improvements.The second goal is to reinforce Agile behavior on existing teams by
spreading the news of the good things those teams have achieved. Finally, the third goal
is to create awareness and interest among those outside the groups directly involved in
adopting Scrum.

Tools for developing Promotion:
• Publicize the success stories
• Host an Agile safari
• Attract attention and interest

Transfer - It is impossible for a development team to remain Agile on its own
permanently. If the implications of using Scrum are not transferred to other
departments, organizational gravity from those departments will eventually stall and kill
the transition effort. By this, I do not mean that the rest of the organization needs to
start using Scrum.What I mean is that the rest of the organization must become at
least compatible with Scrum.
The following is a list of groups to whom you must transfer the implications of using
Scrum. Notice that I have not included testing and product management.These groups
are fundamental participants in Scrum rather than groups to which the effects of Scrum
are transferred.

• Human resources
• Facilities
• Marketing
• Finance
There are groups beyond these to whom you will need to eventually also transfer the
implications of Scrum. For example, you may work with a project management
office, sales, information technology, operations, hardware development, and other
groups with organizational gravity. Transferring the implications of Scrum to them
will be important to your long-term success.

Putting It All Together
Like Scrum itself, ADAPTing to Scrum is iterative. It begins when some in the organization
develop an awareness that the current way of working is no longer
producing acceptable results. As awareness spreads, some individuals develop the
desire to try Scrum in an attempt to improve the situation.Through trial-and-error,
these early adopters within the organization develop the ability to be successful with
Scrum.A new status quo may emerge with a small number of teams successfully
using Scrum within a broader organization that does not. As these initial Scrum teams continue
to improve their use of Scrum, they begin to promote their successes—sometimes informally
as might occur over lunch with friends on another team, other times more formally as in a
department-wide presentation. This helps individuals on other teams begin their own
progressions from awareness to desire to ability.And then soon these other teams begin to
promote their successes as well.

Predictability : Scrum has an iterative, incremental approach to
optimize predictability and control risk.
Sprints enable predictability by ensuring the Scrum Pillars
(Inspection,Transparency and adaptation) and progress to a
Sprint Goal in a Time-box no longer than 30 days. Working in
strict Time-boxes allows us to achieve higher predictability: we
know the dates on which our next Sprints will come out, so it
becomes a question merely of in which Sprint we will work on
the request.

Flexibility:The Scrum framework optimizes flexibility, creativity,
and productivity.
Scrum is about being flexible; if a change arises in the middle of a
sprint we should be able to make it.
Scrum is also about maximizing the delivery of value by a team
over an extended period. One good way of doing so is to allow
the team to retain focus on one goal before redirecting it toward
another. Improving an organization’s flexibility in responding to
strategic changes is different from becoming overly responsive to
the short term, which often leads to unsatisfying long-term
results.

1.2.1 Explain How to Use Continuous Improvement
Historically, when an organization needed to change, it
undertook a “change program.” The change was designed, had
an identifiable beginning and ending, and was imposed from
above.This worked well in an era when change was
necessary only once every few years.Whether you are just
starting to adopt Scrum or you are at the point where you
are ready to fine-tune your use of Scrum, you should manage
the effort in
an Agile way. Following an iterative transition process—
making small changes on a continual basis —is a logical way
to adopt a development process that is itself iterative. Doing
so will be much more likely to result in a successful and
sustainable transition.

The Improvement Backlog
Just as Scrum development projects use Product Backlogs, you
should use an improvement Backlog to track the effort of
adopting Scrum in your organization. An improvement Backlog
lists everything that the organization could do better in its use of
Scrum.
Improvement Backlogs are dynamic, with items coming and going
as they are thought of, completed, found unnecessary, and so on.If
you’re just starting with Scrum, your improvement Backlog will
emphasize creating awareness and desire. If the transition is
already well underway, your improvement Backlog may contain
more items around developing the ability to do Scrum well, to
promote successes, or to transfer it to other groups

The Enterprise Transition Community (ETC)
The small group that initiates, encourages, and supports an organization’s effort to
introduce and improve at Scrum is known as the Enterprise Transition Community, or ETC.1
The ETC exists to create a culture and environment where change can be released by those
who are passionate about the success of the organization and where success leads to more
passion from more people.The ETC does this not by imposing changes on the organization
but by guiding groups who are implementing changes, by removing obstacles to doing Scrum
well, and by creating energy and excitement for the change.

The Enterprise Transition Community (ETC)
Responsibilities of the ETC
An ETC is a working group. It is not a steering committee. During sprint planning, the ETC
commits to completing some amount of work and demonstrating it at the end of the sprint.
However, even more important than the tangible things the ETC
accomplishes is that it ignites the interest of others. Members of the ETC can only
achieve so much themselves.They will need to rely on others in the company to do
most of the work of adopting Scrum and becoming Agile.

Having Scrum temporarily coexist with a sequential process is often necessary in a large organization. But it is
important to remember that Agile is not a destination; being Agile involves continuous improvement.As an
organization attempts to become more and more Agile, the conflicts between Scrum and sequential
development will become more painful. If the sources of these conflicts are not removed, organizational gravity
will pull the organization back to whatever software development process was in place before adopting Scrum.
A few nonthreatening Agile practices such as Daily Scrums or continuous integration might remain, but the
organization will have been unable to achieve the compelling benefits of becoming Agile.
Continuous improvement is easier than it might sound.You’ve planted all the seeds already.Your improvement
communities will play a key role inside the risk-tolerant, idea-generating, nurturing culture fostered by the ETC.
Through trial-and-error experimentation, these communities will lead the organization toward better and
better ways of working. Beyond that, though, they will engage employees’ passion.The organization will shift
from seeing problems to seeing possibilities

1.3 Other Frameworks and other Agile Frameworks
Devops
ATern

1.3.1 Remember other frameworks and
methodologies: Waterfall, Crystal, Lean, XP,
DSDM – Atern, DevOps and CMM
Scrum: A framework within which people can address complex
adaptive problems, while productively and creatively delivering
products of the highest possible value.
Scrum is:
• Lightweight
• Simple to understand
• Difficult to master

XP (Extreme Programming) :Agile method that is focused on
software development best practices.
Extreme programming promotes frequent releases called short
releases.
Extreme Programming’s five common practices :
• Test-Driven Development
• Collective Ownership
• Refactoring
• Continuous Integration
• Pair Programming

Test-Driven Development – A programmer doing test-
driven development, works in very short cycles of identifying
and automating a failing test, writing just enough code to pass
that test, and then cleaning the code up in any necessary ways
before starting again.This cycle is repeated every few minutes,
rather than every few hours.

The microcyclic nature of traditional and
test-driven development.

Collective Ownership - Collective ownership refers to all
developers feeling ownership over all artifacts of the
development process, but especially of the code and automated
tests. Because of the fast pace of a Scrum project, the team
needs to avoid the trap of saying,“That’sTed’s code.We can’t
touch it.” Collective ownership encourages each team member
to feel responsible for all parts of the program so that any
programmer can work on any module of the program.When
modifying a module, the programmer then shares responsibility
for its quality with the module’s initial writer.

Refactoring - Refactoring refers to changing the structure but not the behavior of code.
Let me give you an example. Suppose a programmer has two methods that each contain three
identical statements. These three common statements can be extracted from both methods
and put into one new method that is called from both of the old locations. This refactoring
(formally known as extract method) has slightly improved the readability and maintainability of
the program because it is now more obvious that some code is reused and the duplicated
code has been moved to a single place.The structure of the code has been changed while its
behavior has not.

Continuous Integration - Continuous integration refers to integrating new or
changed code into an application as soon as possible and then testing the application to make
sure that nothing has been broken. Rather than checking in code perhaps every few days or
even every few weeks, each programmer on a Scrum team running continuous integration is
expected to check in code a few times each day—and to run a suite of regression tests over
the entire application.

Pair Programming - Pair programming is the practice of having two developers work
together to write code. It originated from the idea that if occasional code inspections are good,
constant code inspections are better. Many of the practices just described are made easier
through the use of pair programming. Learning how to do test-driven development is made
easier when working together. Feelings of collective ownership are created when code is
produced in pairs.And having the discipline to leave the code cleaner than you found it comes
easier when another developer is sitting beside you.

Lean: Software development projects should seek to maximize business value. Projects should be judged
not on their adherence to cost and schedule milestones, but on their delivery of value to the enterprise.
Value should be delivered as quickly as possible—in small increments—and features should be
prioritized based on the amount of value they deliver.
Five principles of Lean :
1- Specify value from the standpoint of the end customer by product family.
2- Identify all the steps in the value stream for each product family, eliminating whenever possible those
steps that do not create value.
3- Make the value-creating steps occur in tight sequence so the product will flow smoothly toward the
customer.
4- As flow is introduced, let customers pull value from the next upstream activity.
5- As value is specified, value streams are identified, wasted steps are removed, and flow and pull are
introduced, begin the process again and continue it until a state of perfection is reached in which perfect
value is created with no waste.

DSDM (Dynamic Systems Development Method). On DSDM projects,
requirements are sorted into four categories: Must Have, Should Have, Could Have, and
Won’t Have. DSDM refers to this sorting as the MoSCoW rules. No more than 70% of
the planned effort for a project can be targeted at Must Have requirements. In this way,
DSDM projects create a feature buffer equivalent to 30% of the duration of the
project.
DSDM has primarily been used as an approach for IT projects and programmes;
however, it has also been applied on many business change projects and programmes
and the latest version of the DSDM framework – Atern – has been enhanced to
provide clearer support for projects that may have no technology element at all, as well
as continuing to support business solutions where IT plays a major part.

The word DevOps is a contraction of ‘Development’ and ‘Operations’.
DevOps combines a highly automated, repeatable, and testable Continuous Delivery
framework with a unified team that extends through the full lifecycle of delivering
capabilities to production.With a DevOps approach, we can take small batches of
requirements quickly from concept to deployment, monitor the results, and use what
we learn to change the product and the process.

DevOps is commonly recognized to be primarily about creating a culture of effective and seamless
collaboration but this is often the hardest piece to enact when it involves changing an existing culture (as
opposed to creating a culture from scratch in a startup type environment and having the luxury of hiring
individuals with certain mindsets and defining working practices from day one).
Some aspects that have to be considered:
1. Learn to Trust
2. Understand Motivations
3. Eliminate Blame
4. Embrace Smart Failure
5. Focus on Bottlenecks and
Flow
6. Eliminate Unplanned Work
7. Be Continuous
8. Form Dedicated, Cross-
FunctionalTeams
9. Love Transparency
10. Build Autonomy, Mastery
and Purpose

DSDM – Atern ,DevOps and CMM
Waterfall - The Waterfall model was based on taking a point-in-time snapshot of the
information we know and using it to create a long-term plan that we would adhere to.
The business chooses a set of requirements that it believes will add business value. It communicates
them to the IT organization—on paper, of course.The IT organization responds with a plan and
estimates of cost and schedule.The business agrees to the plan.The IT organization executes the plan
and delivers a product to the business.The business accepts the product and then tries to derive
business value from it.This model is the “negotiating a contract” model that the Agile manifesto de-
emphasizes.

DSDM – Atern, DevOps, and CMM
CMM is a framework that describes practices that an organization employs in
developing software. CMM consists of five levels, numbered 1 through 5.
Level 1 (immature organization) means that the organization doesn’t have any defined,
repeatable, or improvable approach to building software; basically, developers hack their
way to a solution.At level 5 (mature organization), an organization has a defined,
repeatable, and improvable set of practices for developing software.At each level, the
practices that should be employed are defined as Key Practice Areas (KPAs). If an
organization believes that it has thoroughly implemented the KPAs for a specific level, it
can engage someone who has been certified by SEI to assess this. If the organization is
compliant, it is so certified. Certification is a big deal, because some companies and
governmental agencies won’t hire any professional services firm that isn’t certified to at
least CMM level 3.

1.4 Applying Agile Principles to IT Service Management
+ ROI
Feedback
Agile
Iteration
Incremental
Develop

1.4.1 Explain how to apply Agile Principles within IT Service
Management
What is Agile?
There are a number of Agile frameworks that in essence are about delivery of value to the customer in
the shortest timescales. In many cases, in the ITIL world, Agile means on time and cost delivery of fit for
purpose services.
Agile is designed for use in complicated, complex or anarchic environments where the environment
changes regularly.This fits very well with the intent of ITIL to continually improve, and also with the
intent of the ITIL framework to be customized to the real world environment.
What is ITIL?
ITIL is part of the Best Management Practice (BMP), family of frameworks, a family of management and
delivery frameworks that have been built from learned best practice, covering complementary topics
such as Portfolio, Program and Project and Service Management.
ITIL provides an excellent framework, or ‘knowledge cube’, to enable delivery and operation of an
effective portfolio of value add services to customers that continuously evolve.

Management
ITIL is not a standard that has to be followed; it is guidance that should be read and understood, and
used to create value for the service provider and its customers. Organizations are encouraged to adopt
ITIL best practices and to adapt them to work in their specific environments in ways that meet their
needs.
ITIL contains five lifecycle stages:
1. Service Strategy
2. Service Design
3. Service Transition
4. Service Operation
5. Continual Service Improvement

Management
Agile focuses on producing ITIL-shaped services within short lead times, or ‘vertical slices’ as they are
known.Vertical slicing is the art of decomposing really big problems into smaller ones so that they can be
focused on and tackled.Within an Agile environment, we aim to produce services (or digestible service
vertical slices) within weeks at best and months at worst.Agile thinking can and should be applied across
the whole of the ITIL framework to ensure that the lead time from the customer’s perspective is as
short as possible. In other words, apply Agile excellence to improve the whole service delivery system,
not parts of the service delivery system.
However, a typical place to start integratingAgile and ITIL is within Service Design and ServiceTransition;
in essence, delivering the changed service in an Agile way. Only focusing Agile into one part of ITIL in this
way does run the risk that, from the customers perspective, the overall service delivery chain (gathering
business requirements through to making the service operational) may still take too long - even though
the delivery capability within Service Design and Transition is Agile and delivers ‘vertical slices’ very
quickly. In other words, just changing one part of the delivery chain may or may not benefit the customer.
If we do focus the initial Agile transformation into the service delivery area between Design and
Transition, then the projects, programs and portfolios that deliver changed services can all be focused
and improved by using Agile.

2.1 Responsibilities and Commitment
Facilitate Scrum Projects
Knowledge of Scrum rules and practices
Help the Team
Help the Product Owner
Remove Impediments
Keep InformationVisibile
Servant Leader
Etc...

2.1.1 Explain which tasks and responsibilities belong to the
Scrum Master role
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 the person who ensures that the team is working well together,
that impediments to progress are quickly removed, and that the team is moving
efficiently toward its goal.
The authority of the Scrum Master is largely indirect; it springs mainly from the Scrum
Master’s knowledge of Scrum rules and practices and his or her work to ensure that
they are followed.The Scrum Master 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 Scrum Master earns no awards or medals because the Scrum
Master is only a facilitator
The Scrum Master is a servant-leader for the Scrum Team.The Scrum Master helps
those outside the ScrumTeam 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.

2.1.2 Explain which solutions are suitable for solving problems
Internal or External Scrum Masters
A common question is whether teams should use Scrum Masters from within the
company or whether outside experts should be brought in.The long-term answer is
easy: Having skilled Scrum Masters is a critical requirement and as such they should
reside within the organization.You should not use contract Scrum Masters over the
long-term.
But it is hard to learn a new skill until you’ve seen someone else demonstrate it.
Learning how to lead without authority, when and how to nudge a team toward
adopting new engineering practices, when it’s OK to intervene, and so on can be
difficult.Therefore, many organizations benefit from bringing in an outside consultant
as a Scrum Master initially.This outsider may act as the Scrum Master to the team, but
he should also serve as a mentor to prospective Scrum Masters within the team so that
the organization can develop its own cadre of Scrum Masters.

Rotating the Scrum Master
Some teams that struggle with choosing the best
Scrum Master decide that an appropriate strategy
is to rotate the role among all team members. I
don’t advocate this, as I don’t think it
demonstrates an appropriate respect for the
challenges and significance of the role. In my family,
we rotate who cleans the table and loads the
dishwasher.Any of us can do that job.We do not,
however, rotate who cooks dinner.
My wife is a far better cook than anyone else in
the family.We want the cooking to be the best it
can be, so we don’t rotate that job. If you want
your Scrum team to be the best it can be, I do not
recommend that you make a habit of rotating the
job of Scrum Master.

Overcoming Common Problems
Some of the common problems you may face in making sure that each team has the
appropriate Scrum Master and what you can do to address them include:
Someone inappropriate takes the role - If you have some authority over the
inappropriate Scrum Master, the team, or the adoption of Scrum, meet with the
volunteer and explain why you need someone different in the role. If not,Try to
accentuate the Scrum Master’s strengths and suggest that he might be able to find a
better way of applying them to the project if he steps out of the Scrum Master role.

2.1.3 Explain which tools to use to facilitate the team
Attributes of a Good Scrum Master
Responsible
A good Scrum Master is able and willing to assume responsibility.
That is not to say that Scrum Masters are responsible for the
success of the project; that is shared by the team as a whole.
However, the Scrum Master is responsible for maximizing the
throughput of the team and for assisting team members in adopting
and using Scrum. As noted earlier, the Scrum Master takes on this
responsibility without assuming any of the authority that might be
useful in achieving it. a good Scrum Master thrives on responsibility—
that special type of responsibility that comes without power.

Humble
A good Scrum Master is not in it for his/her ego. He/She may take
pride (often immense pride) in his/her achievements, but the
feeling will be “look what I helped accomplish” rather than the
more self-centered “look what I accomplished.” A humble Scrum
Master is one who realizes the job does not come with a
company car or parking spot near the building entrance. Rather
than putting his/her own needs first, a humble Scrum Master is
willing to do whatever is necessary to help the team achieve its
goal. Humble Scrum Masters recognize the value in all team
members and by example lead others to the same opinion.

Collaborative
A good Scrum Master works to ensure a collaborative culture exists
within the team.
The Scrum Master needs to make sure team members feel able to
raise issues for open discussion and that they feel supported in doing
so.The right Scrum Master helps create a collaborative atmosphere
for the team through words and actions.When disputes arise,
collaborative Scrum Masters encourage teams to think in terms of
solutions that benefit all involved rather than in terms of winners
and losers.A good Scrum Master models this type of behavior by
working with other Scrum Masters in the organization. However,
beyond modeling a collaborative attitude, a good Scrum Master
establishes collaboration as the team norm and will call out
inappropriate behavior (if the other team members don’t do it
themselves).

Committed
Although being a Scrum Master is not always a full-time job, it does
require someone who is fully committed to doing it.The Scrum Master
must feel the same high level of commitment to the project and the goals
of the current sprint as the team members do. As part of that
commitment, a good Scrum Master does not end very many days with
impediments left unaddressed.There will, of course, be times when this is
inevitable, as not all impediments can be removed in a day. For example,
convincing a manager to dedicate a full-time resource to the team may
take a series of discussions over several days. On the whole, however, if a
team finds that impediments are often not cleared quickly, team member
should remind their Scrum- Master about the importance of being
committed to the team. One way a Scrum Master can demonstrate
commitment is by remaining in that role for the full duration of the
project. It is disruptive for a team to change Scrum Masters mid-project.

Influential
A successful Scrum Master influences others, both on the team and outside it. Initially,
team members might need to be persuaded to give Scrum a fair trial or to behave
more collaboratively; later, a Scrum Master may need to convince a team to try a new
technical practice, such as test-driven development or pair programming.A
Scrum Master should know how to exert influence without resorting to a dictatorial
“because I say so” style. Most Scrum Masters will also be called upon to influence those
outside the team.

Knowledgeable
Beyond having a solid understanding of and experience with Scrum, the best
Scrum Masters also have the technical, market, or other specialized knowledge to help
the team pursue its goal. Scrum Masters do not necessarily need to be marketing gurus
or programming experts, they should know enough about both to be effective in
leading the team.

To achieve long-term success with Scrum, the implications of becoming Agile must be
transferred into other parts of the organization. For example :
Human Resources - Reporting Structures
There is no one reporting structure that must be used to be successful with Scrum. I
have seen functional, project-oriented, and matrixed organizations each be successful.A
matrixed organization will be prone to more challenges, but that should not be
surprising to an organization that has chosen that structure for its other benefits. So,
although I won’t argue strongly in favor of a specific type of organizational structure, I
will say that the organization should be as flat as possible.
The more layers there are between team members and the top of the company, the
more opportunities there are for dysfunctionality to creep in.

2.2 Coaching theTeam and Mediating

2.2.1 Explain when and how to mediate through conflict
Strengthen Functional andTeam Subcultures
Communicate and Establish a Shared Vision
Without a shared vision, it will be almost impossible for a strong team culture to
develop.This makes a shared vision especially important for a distributed team.
Reach Agreements
Part of a team’s culture derives from agreements that team members make with one another.
Some agreements are explicit: Be on time for the Daily Scrum and don’t break the build are
examples.
BuildTrust by Emphasizing Early Progress
Critical to creating a coherent team is building trust among team members.This is
much more difficult on a distributed team.

2.2.2 Explain how to coach and challenge the team
Coaches were given specific responsibilities, such as attend sprint planning, review, and
retrospective meetings; attend one Daily Scrum each week; and be available for two hours each
week to provide other assistance to the mentored team as needed.
• Coaches can be hand-selected for new teams. An approach like the split-andseed
pattern takes a whole-team approach to coaching:The new team is
coached collectively by the seeding team members. Some of those individuals
will be good in that role; some will not.With internal coaching, the most
appropriate coach can be selected for each new team.
• Coaches can be moved from team to team. After awhile a team and its coach
become stale.A fresh pair of eyes can be helpful in identifying new ways to
improve.When internal coaches move from team to team they act like bees,
pollinating each team with new ideas.

2.2.3 Explain the importance of training
On a team that is new to Scrum, the Scrum Master job
can be very time consuming. The Scrum Master will be
busy training team members on Scrum itself, encouraging
them to think in different ways about the problems they
encounter, removing impediments to the team’s
progress, and more. Early on, this might even be a
fulltime job, depending on the newness of the team and
the types of impediments team members face. Over
time, however, things improve. Eventually the Scrum
Master has removed many recurring impediments, and
the team itself has begun to master Scrum
and has embraced its self-organizing nature.As these
changes occur, the team needs less and less of their
Scrum Master’s time.

2.3 Other Roles (Product Owner , Development Team)
PRODUCT OWNER DEVELOPMENT TEAM

2.3.1 Explain all roles with the ScrumTeam
The ScrumTeam
The Scrum Team consists of a Product Owner, the
Development Team, and a Scrum Master. Scrum Teams
are self-organizing and cross-functional. Self-organizing
teams choose how best to accomplish their work,
rather than being directed by others outside the team.
Cross-functional teams have all competencies needed
to accomplish the work without depending on others
not part of the team.The team model in Scrum is
designed to optimize flexibility, creativity, and
productivity.
Scrum Teams deliver products iteratively and
incrementally, maximizing opportunities for feedback.
Incremental deliveries of “Done” product ensure a
potentially useful version of working product is always
available.

2.3.1 Explain all roles within the Scrum Framework
The Product Owner is responsible for maximizing the value of the
product and the work of the Development Team. How this is done may
vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the
Product Backlog. Product Backlog management includes:
I- Clearly expressing Product Backlog items;
II- Ordering the items in the Product Backlog to best achieve goals and
missions;
III- Optimizing the value of the work the Development Team performs;
IV- Ensuring that the Product Backlog is visible, transparent, and clear to all,
and shows what the Scrum Team will work on next; and,
V- Ensuring the Development Team understands items in the Product
Backlog to the level needed.

2.3.1 Explain all roles with the Scrum Team
The Development Team
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 DevelopmentTeam create the Increment.
DevelopmentTeams 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:
They are self-organizing. No one (not even the Scrum Master) tells the
Development Team how to turn Product Backlog into Increments of potentially
releasable functionality; Development Teams are cross-functional, with all of the skills
as a team necessary to create a product Increment;
Scrum recognizes no titles for DevelopmentTeam members other than Developer,
regardless of the work being performed by the person; there are no exceptions to
this rule; Scrum recognizes no sub-teams in the Development Team, regardless of
particular domains that need to be addressed like testing or business analysis; there
are no exceptions to this rule; and, Individual DevelopmentTeam members may have
specialized skills and areas of focus, but accountability belongs to the Development
Team as a whole.

3 Agile Estimating, Planning,
Monitoring and Control

3.1 Writing and maintaining the Product and Sprint
Backlog
Product Backlog Sprint Backlog

3.1.1 Explain why a good Definition of Done is so important
Definition of Done – Defines a potentially shippable product
increment appropriate for its environment. Each Product Backlog item
brought into a sprint will then be expected to comply with these
criteria before being considered complete.
When a Product Backlog item or an Increment is described as “Done”,
everyone must understand what “Done” means. Although this varies
significantly per Scrum Team, members must have a shared
understanding of what it means for work to be complete, to ensure
transparency. This is the definition of “Done” for the Scrum Team and
is used to assess when work is complete on the product Increment.
The same definition guides the Development Team in knowing how
many Product Backlog items it can select during a Sprint Planning.The
purpose of each Sprint is to deliver Increments of potentially
releasable functionality that adhere to the Scrum Team’s current
definition of “Done.”

3.1.2 Create and recognize good User Stories
User Stories are the best way to shift the focus from writing about features to talking
about them. A User Story is a short, simple description of a feature told from the
perspective of the person who desires the new capability, usually a user or customer of
the system. User Stories are often written on index cards or sticky notes, stored in a
shoe box, and arranged on walls or tables to facilitate planning and discussion.As such,
User Stories strongly shift the focus from writing about features to discussing them.
User Stories typically follow a simple template:

3.1.2 Create and recognize good User Stories

3.1.3 Explain how to maintain the Product Backlog and how to
add Product Backlog Items
Fortunately, it is easy to write a Product Backlog that contains features written with
different levels of detail.The Product Backlog items that a team will work on soon
must be known in sufficient detail that each can be programmed, tested, and
integrated within a single sprint.This leads to the User Stories at the top of the
Product Backlog being small but reasonably well understood. User Stories that are
further down are larger and understood in less detail.These epic User Stories are left
large, often known only in enough detail that each can be estimated approximately
and then prioritized.This leads the Product Backlog to take on the shape of an
Iceberg.

Make the Product Backlog DEEP
• Detailed Appropriately. User Stories on the Product Backlog that will be done soon need to be
sufficiently well understood that they can be completed in the coming sprint. Stories that will not be
developed for awhile should be described with less detail.
• Estimated. The Product Backlog is more than a list of all work to be done; it is also a useful planning
tool. Because items further down the Backlog are not as well understood (yet), the estimates associated with
them will be less precise than estimates given items at the top.
• Emergent. A Product Backlog is not static. It will change over time. As more is learned, User Stories
on the Product Backlog will be added, removed, or reprioritized.
• Prioritized. The Product Backlog should be sorted with the most valuable items at the top and the
least valuable at the bottom. By always working in priority order, the team is able to maximize the value
of the product or system being developed.

3.2.1 Explain iterative planning in all the planning moments:
Roadmap, Release and Sprint planning
Product Roadmap – Roadmap is a very useful tool for product
managers.With it you can plan and communicate the vision of the future
that you have for your product.
A roadmap is a high-level visual summary that maps out the vision and
direction of the product offering over time. Ideally, the roadmap should
convey the strategic direction for the product.And it should also tie back
to the strategy for the company.
The roadmap has several ultimate goals:
• Describe the vision and strategy
• Provide a guiding document for executing the strategy
• Get internal stakeholders in alignment
• Facilitate discussion of options and scenario planning
• Help communicate to external stakeholders, including customers
• Clearly articulating the product vision and strategy can make it easier
to secure executive buy-in and to ensure everyone is working toward
a common goal.

Most Agile teams are concerned only with the three innermost levels of the planning
onion. Release planning considers the User Stories or themes that will be developed
for a new release of a product or system.The goal of release planning is to determine
an appropriate answer to the questions of scope, schedule, and resources for a
project. Release planning occurs at the start of a project but is not an isolated effort.
A good release plan is updated throughout the project (usually at the start of each
iteration) so that it always reflects the current expectations about what will be
included in the release.
At the next level is iteration planning, which is conducted at the start of each iteration. Based on
the work accomplished in the just-finished iteration, the product owner identifies high-priority
work the team should address in the new iteration. Because we are looking at a closer horizon than
with release planning, the components of the iteration plan can be smaller. During iteration planning,
we talk about the tasks that will be needed to transform a feature request into working and tested
software.

The Release Plan
Part of planning a release is determining how much can be accomplished by what
date. In some cases, we start with a date and see how much can be finished by then.
In other cases, we start with a set of User Stories and see how long it will take to
develop them. In both cases, once a team has an initial answer, it is assessed against
the organization’s goals for the project:Will the product developed make the desired
amount of money? Will it save enough money? Will the product capture the target
market share? If not, perhaps a longer or shorter project may achieve an acceptable
set of goals.
At a cursory level, determining how much work will fit into a release and what user
stories that will be is a very straightforward process. Multiplying the planned number
of iterations by either the expected or known velocity of the team gives us the total amount of
work that can be performed.

The steps in Release Planning

Sprint Planning - The work to be performed in
the Sprint is planned at the Sprint Planning.This plan
is created by the collaborative work of the entire
Scrum Team.
Sprint Planning is time-boxed to a maximum of eight
hours for a one-month Sprint. For shorter Sprints,
the event is usually shorter.
Sprint Planning answers the following:
What can be delivered in the Increment resulting
from the upcoming Sprint?
How will the work needed to deliver the
Increment be achieved?

Topic One: What can be done this Sprint?
The Development Team works to forecast the functionality that will be developed during the
Sprint. The Product Owner discusses the objective that the Sprint should achieve and the
Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.The
entire Scrum Team collaborates on understanding the work of the Sprint.
The input to this meeting is the Product Backlog, the latest product Increment, projected
capacity of the Development Team during the Sprint, and past performance of the
Development Team.The number of items selected from the Product Backlog for the Sprint is
solely up to the Development Team. Only the Development Team can assess what it can
accomplish over the upcoming Sprint.
After the Development Team forecasts the Product Backlog items it will deliver in the Sprint,
the Scrum Team crafts a Sprint Goal.The Sprint Goal is an objective that will be met within the
Sprint through the implementation of the Product Backlog, and it provides guidance to the
Development Team on why it is building the Increment.

Sprint Goal
The Sprint Goal is an objective set for the Sprint that can be met through the
implementation of Product Backlog. It provides guidance to the Development Team on
why it is building the Increment. It is created during the Sprint Planning meeting.The
Sprint Goal gives the Development Team some flexibility regarding the functionality
implemented within the Sprint.The selected Product Backlog items deliver one
coherent function, which can be the Sprint Goal.The Sprint Goal can be any other
coherence that causes the Development Team to work together rather than on
separate initiatives

3.2.2 Explain the role of the Scrum Master in all the planning
moments: Roadmap, Release and Sprint planning
Sprint Planning - The Scrum Master ensures that the event takes place and that
attendants understand its purpose.The Scrum Master teaches the ScrumTeam to keep
it within the time-box.
A Scrum Master needs to - encourage conversations about the User Stories to keep
happening— before planning meetings, in planning meetings, and after planning
meetings.

3.2.2 Explain the role of the Scrum Master in all the planning
moments: Roadmap, Release and Sprint planning
Avoid Activity-Specific Sprints
A good Scrum Master will continually nudge team members toward adopting improved
technical practices that help them learn how to overlap their work. If a team doesn’t
learn effective ways to do this, team members may settle on a less desirable approach:
activity-specific sprints.An activity-specific sprint is as bad a practice as it would be an
acronym. In this approach, the team decides to use one sprint for analysis and design, a
second sprint for coding, and a third for testing. In this approach, the team is split in
thirds with the analysts working one sprint ahead of the programmers and the testers
working one sprint behind them.

3.3.1 Explain when and how to estimate using Story Points, Ideal
Hours and Ideal Days
Story Points Are Relative
Story Points are a unit of measure for expressing the overall size of a User Story,
feature, or 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 two should be twice as much as a story
that is assigned a one. It should also be two-thirds of a story that is estimated as three
Story Points.
The number of Story Points associated with a story represents the overall size of the
story.There is no set formula for defining the size of a story. Rather, a story-point
estimate is an amalgamation (combination) of the amount of effort involved in developing the
feature, the complexity of developing it, the risk inherent in it, and so on.

Ideal Days - When we estimate the number of ideal days that a User Story will take
to develop, test, and accept, it is not necessary to consider the impact of the overhead
of the environment in which the team works.
When estimating in ideal days, you assume
• The story being estimated is the only thing you’ll work on.
• Everything you need will be on hand when you start.
• There will be no interruptions.

Ideal Hours – It’s the same as Ideal Days, only using Hours as difference.
When we estimate the number of ideal hours that a User Story will take to develop,
test, and accept, it is not necessary to consider the impact of the overhead of the
environment in which the team works.
When estimating in ideal hours, you assume
• The Story being estimated is the only thing you’ll work on.
• Everything you need will be on hand when you start.
• There will be no interruptions.

3.3.2 Explain how to guide a planning session, with and without
Planning Poker

Planning Poker
Planning Poker - Planning poker combines expert opinion, analogy, and disaggregation into an
enjoyable approach to estimating that results in quick but reliable estimates.
Participants in planning poker include all of the developers on the team. Remember that
developers refers to all programmers, testers, database engineers, analysts, user interaction
designers, and so on. On an Agile project, this will typically not exceed ten people. If it does, it
is usually best to split into two teams. Each team can then estimate independently, which will
keep the size down.The product owner participates in planning poker but does not estimate.
At the start of planning poker, each estimator is given a deck of cards. Each card has written on
it one of the valid estimates. Each estimator may, for example, be given a deck of cards that
reads 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.The cards should be prepared prior to the planning
poker meeting, and the numbers should be large enough to see across a table. Cards can be
saved and used for the next planning poker session.

Planning Poker
When to Play Planning Poker
Teams will need to play planning poker at two different times. First, there will
usually be an effort to estimate a large number of items before the project officially
begins or during its first iterations. Estimating an initial set of User Stories may take a
team two or three meetings of from one to three hours each. Naturally, this will
depend on how many items there are to estimate, the size of the team, and the product
owner’s ability to clarify the requirements succinctly.
Second, teams will need to put forth some ongoing effort to estimate any new stories that are
identified during an iteration. One way to do this is to plan to hold a very
short estimation meeting near the end of each iteration. Normally, this is quite
sufficient for estimating any work that came in during the iteration, and it allows new
work to be considered in the prioritization of the coming iteration.

Planning Poker
Without Planning Poker - The Estimation Scale
Studies have shown that we are best at estimating things that fall within one order of magnitude .Within your town, you should be able to
estimate reasonably well the relative distances to things like the nearest grocery store, the nearest restaurant, and the nearest library.The
library may be twice as far as the restaurant, for example.Your estimates will be far less accurate if you are asked also to estimate the
relative distance to the moon or a neighboring country’s capital. Because we are best within a single order of magnitude, we would like to
have most of our estimates in such a range.
Two estimation scales I’ve had good success with are
• 1, 2, 3, 5, and 8
• 1, 2, 4, and 8
There’s a logic behind each of these sequences.The first is the Fibonacci sequence.[1] I’ve found this to be a very useful estimation sequence
because the gaps in the sequence become appropriately larger as the numbers increase.A one-point
gap from 1 to 2 and from 2 to 3 seems appropriate, just as the gaps from 3 to 5 and from 5 to 8 do.The second sequence is spaced such
that each number is twice the number that precedes it.These nonlinear sequences work well because they reflect
the greater uncertainty associated with estimates for larger units of work. Either sequence works well.

3.3.3 Recognize errors in estimation
The Purpose of Re-Estimating
Do not become overly concerned with the need to re-estimate.
Whenever the team feels one or more stories are misestimated
relative to other stories, re-estimate as few stories as possible to
bring the relative estimates back in line. Use re-estimating as a
learning experience for estimating future User Stories.“Failure to
learn is the only true failure.” Learn from each re-estimated story,
and turn the experience into a success
Remembering that Story Points ,ideal days and ideal hours are
estimates of the size of a feature helps you know when to re-
estimate.You should re-estimate only when your opinion of the
relative size of one or more stories has changed. Do not re-
estimate solely because progress is not coming as rapidly as you’d
expected. Let velocity, the great equalizer, take care of most
estimation inaccuracies.

3.3.3 Recognize errors in estimation
When to Re-Estimate
Scenario 1: No Re-Estimating
In this scenario, we will leave all estimates alone.The team achieved a velocity of
eight points in the last iteration.That leads us to the expectation that they’ll average
eight points in the upcoming iterations. However, the team knows they cannot
complete Stories 2 and 3 in a single iteration, even though they represent only eight
points. Because each of those stories involves charting, and because the team expects
each charting story to be twice as big as its current estimate (just like story 1 was),
the team concludes that they cannot do Stories 2 and 3 in one iteration. It’s eight
points, but it’s too much.

3.3.4 Explain how to calculate the ROI (Return on Investment)
Sources of Return
The return on a project can come from a variety of sources. For convenience, we can
categorize these as new revenue, incremental revenue, retained revenue, and
operational efficiencies. Although it is common for one category to dominate the
return of a specific project, most projects will earn returns from more than one
category.
• New Revenue
• Incremental Revenue
• Retained Revenue

Net PresentValue
To determine NPV, sum the present values of each item in a stream of future values.
The formula for doing so is :
Where I is the interest rate and Ft is the net cash flow in period t.

Internal Rate of Return
Internal Rate of Return (IRR, and sometimes called Return on Investment or ROI)
provides a way of expressing the return on a project in percentage terms.Where NPV
is a measure of how much money a project can be expected to return (in today’s
present value), IRR is a measure of how quickly the money invested in a project will
increase in value.With IRR we can more readily compare projects, as shown in
Table 10.11.Which project would you prefer?

Most people would prefer to make 43% on their money, even though the NPV is
higher for Project A, which also requires the higher initial investment. Cash flows for
these two projects are shown below :

IRR is defined as the interest rate at which the NPV of a cash flow stream is equal to
0. In other words, it is the value for i* such that
PV = Present Value
Ft = Net Cash flow
T = Period

3.4Tracking and communicating progress

3.4.1 Identify impediments, deviations, roadblocks and other
obstacles that influence the progress positively and negatively
Scrum turns small teams into managers of their own fate.We know that when we are responsible for
choosing our own driving route to Boston, we will find a way to get there.We will detour around
construction and avoid rush hour traffic jams, making decisions on the fly, adapting to the independent
decisions of all of the other drivers out there. Similarly, Scrum Teams accept a challenge and then figure
out how to meet that challenge, detouring around roadblocks in creative ways that could not be planned
by a central control and dispatching center. If teams are of a size that encourages every member to
participate, and team members feel like they are in control of their own destiny, the experience, ideas,
and concerns of individual members will be leveraged, not squelched.When team members share a
common purpose that everyone believes in, they will figure out how to achieve it.When teams
understand and commit to delivering business value for their customers, when they are free to figure out
how to perform tasks, and when they are given the resources they need, they will succeed.

3.4.2 Explain how to create Information Radiators, how to
interpret them and how to act on the results
TheTask Board
A task board serves the dual purpose of giving a team a convenient mechanism for
organizing their work and a way of seeing at a glance how much work is left. It is
important that the task board (or something equivalent to it) allow the team a great
deal of flexibility in how they organize their work. Individuals on an Agile team do
not sign up for (or get assigned) work until they are ready to work on it.This means
that except for the last day or two of an iteration, there typically are many tasks that
no one has yet signed up for. A task board makes these tasks highly visible so that
everyone can see which tasks are being worked on and which are available to sign
up for.

Example of aTask Board

The Gantt Chart
Some companies have become accustomed to communicating project schedules through the familiar
Gantt chart, have earned a bad reputation, but this is because of how they are often used to predict,
schedule, and coordinate tasks. Despite these challenges in their use, Gantt charts can be great tools for
showing the allocation of features to iterations.

Communicating Progress
Naturally, the release burndown charts are a primary way of communicating progress.
Progress on a release burndown chart is a function of the amount of work remaining and the velocity of
the team.The simple way to predict the number of iterations remaining is to take the
number of points remaining to be developed, divide this by the team’s velocity, and then round up to
next whole number. So if there are 100 points remaining and the team’s velocity is 10, we could say there
are 10 iterations remaining. However, measures of velocity are imprecise, and we expect velocity to
fluctuate. If a team has determined their average velocity is ten, it is not inconceivable that it averages
nine or eleven for the next few iterations. In fact, it’s not inconceivable for velocity to be seven or
thirteen over the next few iterations. In those cases, there could be as few as eight or as many as fifteen
iterations left.When forecasting the
number of iterations remaining, it generally is best to use a range of probable velocities.

3.4.3 Explain commonly used tracking methods (Burn-Down
Chart,Velocity,…)
Velocity
To understand how estimating in unitless Story Points can possibly work, it is
necessary to introduce a new concept: velocity. Velocity is a measure of a team’s
rate of progress. It is calculated by summing the number of Story Points assigned to
each User Story that the team completed during the iteration.[1] If the team completes
three stories each estimated at five Story Points, their velocity is fifteen. If the team
completes two five-point stories, their velocity is ten.
If a team completed ten Story Points of work last iteration, our best guess is that they
will complete ten Story Points this iteration. Because Story Points are estimates of
relative size, this will be true whether they work on two five-point stories or five
two-point stories.

Chart,Velocity,…)
Burndown Charts
The vertical axis shows the number of Story Points remaining in the project. (It could just
as easily show the number of ideal days remaining.) Iterations are shown across the
horizontal axis.A burndown chart shows the amount of work remaining at the
start of each iteration.This becomes a powerful visual indicator of how quickly a team is moving toward
its goal.The picture in the next slide shows a hypothetical burndown for a project with 240 Story Points
delivered in equal amounts over eight iterations. Of course, it’s unlikely that a team that expects to have
a velocity of thirty will have that exact velocity in each iteration.
A burndown chart shows the amount of work remaining across time.The burndown chart is an excellent
way of visualizing the correlation between the amount of work remaining at any point in time and the
progress of the project Team(s) in reducing this work.The intersection of a trend line for work remaining
and the horizontal axis indicates the most probable completion of work at that point in time.

Chart,Velocity,…)
Example of a Burndown Chart

Chart,Velocity,…)
A Burndown Bar Chart
At one level, the release burndown chart is great. It’s easy to understand and can be explained quickly to
anyone in the organization.A release burndown chart like this is very informative and tells us when the
project is likely to finish if all factors affecting the project remain unchanged. However, sometimes it’s
useful to draw the release burndown chart so that you can easily see the team’s velocity and the scope
changes separately.To do this, draw a release burndown bar
chart like the one showed in the next slide
A Caveat on Using the Release Burndown Bar Chart
a couple of caveats on its use. First, the burndown bar chart is harder to understand, so I almost always
start a new team with the simpler burndown line chart. Second, the burndown bar chart is for use only
in organizations mature enough not to argue about whether something
belongs above the line or below the line.

Chart,Velocity,…)
Example of a Burndown Bar

Chart,Velocity,…)
A Parking-Lot Chart
A parking-lot chart contains a large rectangular box for each theme (or grouping of
User Stories) in a release. Each box is annotated with the name of the them, the
number of stories in that theme, the number of Story Points or ideal days for those
stories, and the percentage of the Story Points that are complete.
Example of a Parking-Lot Chart.

3.5.1 Explain how to manage issues, bugs and informing people
outside of theTeam
Tracking Bugs on aTask Board
Many teams, when they begin the transition to an Agile development process,
are faced with a large number of legacy bugs. Not only is there usually a large
Backlog of bugs to be fixed “someday,” but also bugs continue to come in at a
rapid rate. A common challenge for teams moving to an Agile process is how to
deal with these bugs.The task board provides a convenient mechanism for
starting to correct this problem.As an example of how the task board can help,
suppose the product owner includes “Fix ten ‘high’ bugs” in the new iteration.
The product owner selects the ten bugs, and the developers write a task card
(with an estimate) for each.The cards are taped in the To Do column of a row
on the task board. As the iteration progresses, the developers work on the ten
bugs in the same way they work on other task cards. Now suppose a user finds
a new bug halfway through the iteration. If the new bug is considered a higher
priority than one or more bug remaining in the To Do column, the product
owner can swap out an equivalent amount of bug fixing work in favor of fixing
the new bug.

3.5.1 Explain how to manage issues, bugs and
informing people outside of theTeam
The customer, who is the person purchasing the product,
and the user, who is the individual using the product,
determine the success or failure of the product. Only if
enough customers buy the product and the users find it
beneficial, will the product be a success in the
marketplace. Notice that the customer and the user may
not be the same person.They may also not have the
same needs.Take the example of an electronic
spreadsheet.The needs of its users might include ease of
use and high productivity.The company purchasing the
product, on the other hand, might be concerned about
the total cost of ownership and data security..

4.1.1 Explain how to use the Product Backlog in a scaled
environment
Working in Large Projects
Large projects are often more critical to the organization, under greater scrutiny, more time-
sensitive, more prone to personality clashes, longer, and more likely to be distributed across
multiple sites.
Working with a Large Product Backlog
Most large project teams opt to use one of the commercial Agile tools that provide support
for working with a large Product Backlog. I won’t, therefore, go into all of my preferences for
how to work with a single large Product Backlog because much of how an organization works
with its Product Backlog will be dictated by its tool selection. There are, however, two
guidelines worth pointing out that remain valid regardless of which Backlog management tool
is selected:
• If there’s only one product, there should be only one Product Backlog.
• The Product Backlog should be kept to a reasonable size.

environment

environment
Although this may seem to be a small number of Product Backlog items, consider that
we have two ways of keeping the number of Backlog items manageable :
• Make use of epics and themes.
• Provide views into the Product Backlog.

4.1.2 Explain how to scale to larger teams using both Scrum-of-
Scrums and SAFe-framework
The Scrum of Scrums
A Scrum of Scrums is the usual mechanism that coordinates multiple teams working on a
single project, much as the Daily Scrum is the mechanism that coordinates the work of
multiple people on a single team.A Scrum of Scrums is a Daily Scrum consisting of one
member from each team in a multi-team project. Before a project officially begins, the planners
of the project parse the work among teams to minimize dependencies.Teams then work on
parts of the project architecture that are orthogonal to each
other. However, this coordination mechanism is effective only when there are minor couplings
or dependencies that require resolution.The dependencies at Tree were so significant that a
Scrum of Scrums wouldn’t work.
A fairly universal practice for coordinating work among several teams is the Scrum of Scrums
meeting.These meetings allow clusters of teams to discuss their work, focusing especially on
areas of overlap and integration.

Scrum of Scrums meetings can be applied recursively at as many layers
as needed to coordinate work among clusters of teams.

The Scaled Agile Framework™ is a proven codified, and publicly-facing knowledge base that is used
to successfully scale lean and Agile development in larger software enterprises. It has been successfully
applied in programs ranging from 50-100 people, to enterprises employing thousands of
software developers.
It is structured in three levels: time, program and portfolio.At the base of the structure is the team, and
here the SAFe will be used in the organization of the teams, according to their talents and abilities. In the
next level - program - there is the integration of all the work done by different teams, which must be
synchronized with other areas. Usually this happens through events, or ceremonies, which can be
planning,periodic monitoring or review.
Finally, we reach the level of the portfolio, where the framework allows to manage the organizational
demands. Here, this is done in an Agile way, seeking to discover the operational bottlenecks of the
company and, mainly, guiding initiatives to what is most important, which will generate more economic
value for the operation.

4.2.1 Explain in which cases it is not possible to
use Agile
Having Scrum temporarily coexist with a sequential process is often necessary in a
large organization. But it is important to remember that Agile is not a destination; being
Agile involves continuous improvement. As an organization attempts to become more
and more Agile, the conflicts between Scrum and sequential development will become
more painful. If the sources of these conflicts are not removed, organizational gravity
will pull the organization back to whatever software development process was in place
before adopting Scrum. A few nonthreatening Agile practices such as Daily Scrums or
continuous integration might remain, but the organization will have been unable to
achieve the compelling benefits of becoming Agile.

4.2.1 Explain in which cases it is not possible to
use Agile
All change is hard. It’s not hard to see employees in an uproar over something so small
as a change in their company’s healthcare plan. Larger changes can be even more
painful.
But there are certain attributes of transitioning to Scrum that make it more difficult
than most other changes.They are as follows:
• Successful change is not entirely top-down or bottom-up.
• The end state is unpredictable.
• Scrum is pervasive.
• Scrum is dramatically different.
• Change is coming more quickly than ever before.
• Best practices are dangerous.

4.2.2 Identify the limits of a Scrum Team
What is the ideal team size for Scrum projects?
Generally accepted advice is that the ideal Scrum team size is five to nine individuals.
Large teams may include members with more diverse skills, experiences, and approaches. Large
teams are not as much at risk to the loss of a key person.They may also provide more
opportunities for individuals to specialize in a technology or a subset of the application.
On the other hand, there are even more advantages to small teams.These include the
following:
There is less social loafing, - Constructive interaction is more likely to occur on a small team -
Less time is spent coordinating effort - No one can fade into the background - Small teams are
more satisfying to their members - Harmful over-specialization is less likely to occur

4.3.1 Explain which tools can help a Team to use or adopt Agile
and thereby increase the quality of the development process
Start Small or Go All In
Conventional, long-standing advice regarding transitioning to Scrum or any Agile process has
been to start with a pilot project, learn from it, and then spread Agile throughout the
organization.This approach is the frequently used start-small pattern in which an organization
selects typically one to three teams (of five to nine people each), gets them successful, and then
expands Scrum from there.As Scrum spreads through the organization, new teams benefit
from the lessons learned by the teams that have gone before.There are many variations of
start small, depending on how many people the organization wants to transition and how
quickly they want to do it. Start small can also be applied differently based on how risk-averse
or uncertain about the transition the organization is. For example, in some cases the first team
or teams will finish their projects before a second set of teams even begins. Other
organizations will take an overlapping approach, where the second set of teams starts only one
or two sprints after the first.

Choosing Between Going All In and Starting Small
As I mentioned at the start of this chapter, starting small has been the default
approach recommended by most Agile authors and used in most Agile adoptions.The
combination of this approach’s low risk and high likelihood of success make it hard
to find fault with.Always choose to start small when there is a reluctance by leaders
in the organization to fully commit to Scrum. Success, even on a small scale, can be
the best way to convince the skeptics.Always start small when there is a high cost
associated with failure. If the cost of failure is too high for those leading the
transition, starting small is the way to go, even if it may not be best for the
organization as a whole. Start small is probably not the best approach when your
organization urgently needs the benefits of Scrum. (But if you do choose to start
small, scale quickly.) Starting small is safe, but it’s slow.

Public Display of Agility or Stealth
The next choice to make is whether or not to publicize your transition. One option is
to make a public display of agility. In this approach, the team or organization
announces with great fanfare that it is adopting Scrum. Depending on the scope and
significance of the transition, the announcements may range from lunchroom
comments to other teams all the way up to press releases in the national media. No
matter the extent of the publicity, with a public display of agility, teams make an
effort to inform others that something Agile is going on.
In contrast to a public display of agility is a stealth transition. In a stealth transition,
only the team members know they are using Scrum until the project is complete.

5.1 Introducing Agile
The Sprint
The heart of Scrum is a Sprint, a time-box of one month or
less during which a “Done”, useable, and potentially releasable
product Increment is created. Sprints best have consistent
durations throughout a development effort. A new Sprint
starts immediately after the conclusion of the previous Sprint.
Sprints contain and consist of the Sprint Planning, Daily
Scrums, the development work, the Sprint Review, and the
Sprint Retrospective.
During the Sprint:
• No changes are made that would endanger the Sprint Goal;
• Quality goals do not decrease; and,
• Scope may be clarified and re-negotiated between the
Product Owner and Development Team as more is learned.

Daily Scrum
The Daily Scrum is a 15-minute time-boxed event for the
Development Team to synchronize activities and create a
plan for the next 24 hours.This is done by inspecting the
work since the last Daily Scrum and forecasting the work
that could be done before the next one.
The Daily Scrum is held at the same time and place each day
to reduce complexity. During the meeting, the Development
Team members explain:
• What did I do yesterday that helped the Development
Team meet the Sprint Goal?
• What will I do today to help the Development Team
meet the Sprint Goal?
• Do I see any impediment that prevents me or the
Development Team from meeting the Sprint Goal?

Sprint Review
A Sprint Review is held at the end of the Sprint to
inspect the Increment and adapt the Product Backlog if
needed. During the Sprint Review, the Scrum Team and
stakeholders collaborate about what was done in the
Sprint. Based on that and any changes to the Product
Backlog during the Sprint, attendees collaborate on the
next things that could be done to optimize value.This is
an informal meeting, not a status meeting, and the
presentation of the Increment is intended to elicit
feedback and foster collaboration.
This is a four-hour time-boxed meeting for one-month
Sprints. For shorter Sprints, the event is usually shorter.
The Scrum Master ensures that the event takes place
and that attendants understand its purpose.The Scrum
Master teaches all to keep it within the time-box.

Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to inspect
itself and create a plan for improvements to be enacted during the next
Sprint.
The Sprint Retrospective occurs after the Sprint Review and prior to the
next Sprint Planning.This is a three-hour time-boxed meeting for one-month
Sprints. For shorter Sprints, the event is usually shorter.The Scrum Master
ensures that the event takes place and that attendants understand its
purpose.The Scrum Master teaches all to keep it within the time-box.The
Scrum Master participates as a peer team member in the meeting from the
accountability over the Scrum process.
The purpose of the Sprint Retrospective is to:
• Inspect how the last Sprint went with regards to people, relationships,
process, and tools;
• Identify and order the major items that went well and potential
improvements; and,
• Create a plan for implementing improvements to the way the Scrum
Team does its work.

Sprint Backlog
The Sprint Backlog is the set of Product
Backlog items selected for the Sprint, plus a
plan for delivering the product Increment and
realizing the Sprint Goal.The Sprint Backlog is
a forecast by the Development Team about
what functionality will be in the next
Increment and the work needed to deliver
that functionality into a “Done” Increment.
The Sprint Backlog makes visible all of the
work that the Development Team identifies as
necessary to meet the Sprint Goal

Increment
The Increment is the sum of all the Product Backlog items completed during a Sprint
and the value of the increments of all previous Sprints. At the end of a Sprint, the new
Increment must be “Done,” which means it must be in useable condition and meet the
Scrum Team’s definition of “Done.” It must be in useable condition regardless of
whether the Product Owner decides to actually release it.

Timeboxes
A period of time that cannot be exceeded and within which an event or meeting
occurs. For example, a Daily Scrum meeting is time-boxed to 15 minutes and
terminates at the end of those 15 minutes, regardless.

5.1.1 Explain which project management activities are important
to include in the transition plan
Selecting a Pilot Project - A pilot project is undertaken to provide guidance
to subsequent projects; it pilots the way in doing something new. It is this second
meaning that I’m interested in—the pilot that leads the way rather than the one that is
conducted as a test.As an industry we have enough evidence that Scrum works; what
individual organizations need to learn is how to make Scrum work inside their
organizations. So, they often conduct one or more pilots as learning projects.

5.1.1 Explain which project management activities are important
to include in the transition plan
Four Attributes of the Ideal Pilot Project

5.1.2 Explain which milestones are important in the transition
WhyTransitioning Is Hard
All change is hard. I’ve seen employees in an uproar over something so small as a change in
their company’s healthcare plan. Larger changes can be even more painful.But there are certain
attributes of transitioning to Scrum that make it more difficult than most other changes.They
are as follows:
• Successful change is not entirely top-down or bottom-up.
•The end state is unpredictable.
• Scrum is pervasive.
• Scrum is dramatically different.
• Change is coming more quickly than ever before.
• Best practices are dangerous.

Why It’s Worth the Effort
Despite all the reasons why transitioning to Scrum can be particularly difficult,
stakeholders in companies that have made the transition are happy they’ve done so.
One reason stakeholders are so satisfied is that time-to-market is reduced when using
an Agile process like Scrum.This faster time-to-market is enabled by the higher
productivity of Agile teams, which is in turn the result of the higher quality seen on
Agile projects. Because employees are freed up to do high-quality work and because
they see their work delivered sooner into the hands of waiting users, job satisfaction
goes up.With higher job satisfaction comes more engaged employees, which leads to
more productivity gains, initiating a virtuous cycle of continued improvement

In the sections below we look at these reasons why transitioning to an Agile
process like Scrum is worthwhile:
• Higher productivity and lower costs
• Improved employee engagement and job satisfaction
• Faster time to market
• Higher quality
• Improved stakeholder satisfaction
• What we’ve been doing no longer works

5.1.3 Explain how to deal with resistance to change
Anticipating Resistance
It should not be surprising that some people will resist the change to Scrum. Some
people resist all change.A transition such as the one to Scrum brings great upheaval to
the organization. Responsibilities broaden, reporting relationships are altered,
organizational power shifts, and expectations change. Some individuals stand to gain
personally or professionally from such changes; others stand to lose. Understanding
how these shifts will affect your organization is vital to anticipating where resistance
will occur.

The top reasons for resisting change, as given by employees and managers.

Consider the following activities to help bring pragmatists around to
Scrum:
• Run a pilot project and include pragmatists on the team.
• Make sure pragmatists who aren’t on the pilot team see the results of it.
• Provide training to pragmatists.
• Expose pragmatists to the successes of other companies through conferences,
regional Agile interest groups, and so on.
• Be open to the drawbacks and challenges of Scrum rather than overselling it as
a silver bullet.
• Involve pragmatists on the improvement communities

The Hows and Whys of Individual Resistance
People resist changing to Scrum for Just as there are many reasons why some people
will resist Scrum, there are many ways someone might resist. One person may resist
with well-reasoned logic and fierce arguments. Another may resist by quietly
sabotaging the change effort.“You think no documentation is a good idea? I’ll show you
no documentation,” the passive resistor may think, proceeding to write nothing down,
even bug reports the team has agreed should continue to be stored in the defect
tracking system.Another may resist by quietly ignoring the change, working the old way
as much as possible, and waiting for the next change du jour to come along and sweep
Scrum away.many different reasons.

Categorizing how individuals resist is even simpler:
Is the resistance active or
passive? Active resistance occurs when someone
takes a specific action intended to impede or derail
the transition to Scrum.
Passive resistance occurs when someone fails to
take a specific action, usually after saying he will.
Combining the two general reasons people may
resist Scrum with the two ways in which they will
do it leads to the standard two-by-two matrix.

Skeptics
Thad had no choice but to adopt Scrum. His company had been acquired and was
being told by the new owners to begin using Scrum immediately.This wasn’t a direction
Thad would have chosen himself, and he had serious concerns about it.Would the Daily
Scrums add value, especially with a product owner who worked from her home 600
miles away? How could a new product as complicated, large, and novel as theirs be
done without a lengthy up-front design phase? He could see the value of iterating
through the construction phase, but surely an up-front design was still needed.Thad
was a skeptic. I knew this from his willingness to admit that Scrum was fine for other
domains, technologies, or environments—just not his.

Skeptics
Some of the tools that are useful in overcoming the resistance presented by skeptics include :
• Let time run its course.
• Provide training.
• Solicit peer anecdotes.
• Appoint a champion skeptic.
• Push the issue.
• Build awareness.

rumgileebookasc

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a rumgileebookasc

Semelhante a rumgileebookasc (20)

Mais de Anne Starr

Mais de Anne Starr (20)

Último

Último (20)

rumgileebookasc