StarAgile CSM ParticipantWorkBook 2017

Name :
Certified ScrumMaster
WORKSHOP
I hear and I forget, I see and I remember, I do and I understand
- Confucius
Narasimha Reddy Bommaka

narasimha@staragile.com
NarasimhaBommaka
9880687685
Table of Content
1. Working Agreements....................................................................... 3
2. Defined vs. Empirical Process .....................................................4 – 6
3. Iterative & Incremental Development ............................................. 7
4. Agile Introduction................................................................. 8 – 9
5. Agile Manifesto and Principles ..............................................10 – 12
6. Scrum Introduction ........................................................... 13 – 14
7. Scrum Framework…………………………………………………………………….15, 19
8. The Sprint................................................................................ 16
9. Scrum Roles ...........................................................................20 – 27
10. Product Backlog and Product Backlog Refinement ................. 28 – 32
11. User Stories and Acceptance Criteria ............................................. 33
12. Definition of Done ................................................................... 35
13. Estimation ........................................................................ 36 – 38
14. Sprint Planning… ....................................................................... 39 – 40
15. Sprint Backlog and Sprint Goal...................................................... 41
16. Daily Scrum ........................................................................... 42 – 43
17. Sprint Review ........................................................................ 45 – 46
18. Sprint Retrospective .............................................................. 47 – 50
19. Release Planning… ............................................................................. 51
20. Sprint Burn-Down and Release Burn-Up Charts…………..17 – 18, 34, 44
21.Scrum Alliance Certification Details ............................................... 52
22.Scrum Case Studies .................................................................... 55 – 57
Copyright 2017 – 2020 Narasimha Reddy 2

B k
Working Agreements

B k
Different ways to do something:
Defined & Empirical Process

B k
Empirical Process
Source: http://www.reliableplant.com/Read/29071/plan-continuous-improvement
DEFINED PROCESS -> CONTROLLED & COORDINATED

EMPIRICAL PROCESS -> TRANSPARENT & INSPECT & ADAPT
Empirical process is generally used for handling projects that are complex and
not very well understood.
Write below one activity (outside work) that you have done using Empirical
process. Please share it with the person sitting next to you.

B k
Three pillars of Empirical Process
T
I
A

B k
Iterative & Incremental Development
Source: http://www.agileproductdesign.com/blog/dont_know_what_i_want.html
Courtesy: Jeff Patton
Developing a system through repeated cycles (iterative) and in smaller

portions at a time (incremental)

B k
Why Agile?
Source: http://216.119.127.164/edgeware/archive/think/main_aides3.html
Agile Frameworks like Scrum are better suited to deal with Complex problems
where there is lot of ambiguity and would need inspect, adapt cycles to shape
the product. Scrum can be used in Simple, Complicated problems as well.
However Scrum may not be effective while dealing with anarchy systems.
What is the success rate of Traditional Projects & Agile Projects in Software
industry?

B k
What is Agile?
Agile is a mindset – a set of values and principles.
Source: http://www.agilesherpa.org/intro_to_agile/what_is_agile_development/

B k
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:
over processes and tools
over comprehensive documentation
over contract negotiation
over following a plan.
That is, while there is value in the items on the , we value the items on
the more.
Source: http://www.agilemanifesto.org
B k
Principles behind 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.

B k
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.
Source: http://www.agilemanifesto.org

B k
Scrum
Source: https://www.networld-sports.co.uk/blog/index.php/2015/09/22/rugby-explained-the-scrum/
Creators of Scrum:
Scrum Guide:
http://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-
US.pdf#zoom=100

B k
What is Scrum?
Scrum is a development framework based on empirical process control
wherein self organizing and cross functional teams deliver potentially
shippable product increment every thirty days or less. Scrum employs
iterative and incremental approach to optimize value delivery and to manage
risks.
Scrum is founded on empiricism and the three pillars of empiricism are

transparency, inspection, adaptation. The values that make a scrum team
successful are Focus, Openness, Respect, Courage, and Commitment.
Questions to ponder over with someone in the class:
What happens when Scrum practices are implemented without considering Scrum
values?
Which of the Scrum values could have significant impact in your team?

B k
Scrum Framework

B k
The Sprint
Sprint is a time-box of one month or less and is a container of all other events
– Sprint planning, Daily Scrum, Sprint Review, Sprint Retrospective. A new
Sprint starts immediately after the end of previous Sprint.
During Sprint, Scrum team works together to create a potentially shippable

product increment.
 Sprint enables predictability
 Sprint limits risk
 Sprint duration should be consistent throughout the development effort
 Sprint ends only when time-box expires
Factors influencing the duration of Sprint:
In Scrum, all events are time-boxed.

B k
Sprint 2 - Burn Down chart
What is the purpose of a Sprint Burn Down Chart?
What do you measure in a Sprint Burn Down Chart?
What is the Velocity of this Sprint?

B k
Release Burn Up Chart
At the end of each Sprint, update the release burn up chart.

B k
Scrum Framework

B k
Scrum Roles
Development Team:

B k
Development Team:
• All professionals with the skills required to create the working product
are part of Development Team.
• Primary responsibility of the Development Team is to deliver a

potentially shippable product increment at the end of each Sprint.
• Self-Organizing -> empowered to manage, organize their own work to

create potentially shippable product. Development team alone
determine “how” to build to accomplish the Sprint Goal.
• Cross-functional -> Have all the skills necessary as a team to create a

product increment.
• Responsible for the Quality and Design of the product.
• No silos (sub-groups) and no appointed leaders in the Team.
• Ideally co-located and have fully committed/allocated to the project.
• Ideal Team size is 6 +/- 3 (Fewer than Nine and more than Three).
• Individuals in the team may have specialized skills, but accountability

belongs to the whole Development Team.
• Owns and manages the Sprint Backlog. Decides on how much work can be
taken up in a Sprint.
• Participates in all Scrum Events – Sprint Planning, Daily Scrum, Sprint

Review, Sprint Retrospective
• Updates Sprint Burn-Down charts and Task boards
• Estimates items in the Product Backlog
• Helps Product owner in Product Backlog Refinement

B k
• Continuously improve and Help other team members by cross training
skills
Points to Ponder:
What happens when the Development Team consists of fewer than 3 team
members or more than 9 members?
What happens when some one other Product Owner also starts offering
work to the Development Team?

B k
Scrum Master:

B k
Scrum Master:
• Servant Leader – No direct authority. Leads through influence.
• Change Agent
• Not a manager (Cannot make decisions on behalf of the Team or Product

Owner)
• Focus on People development than on getting results
• Process Owner – serves as authority for Scrum framework and upholds

Scrum values in the Scrum Team
Service to the Development Team
• Teaches Scrum and ensures that the Development team members

understand and adheres to Scrum theory, practices and rules
• Protects from external disturbances
• Facilitates Scrum Events as needed
• Coaches Team in Self-Organization and Cross-functionality
• Makes Impediments visible and helps Scrum Team to

track and resolve them.
• Removes impediments (when requested) and gets outside help

for the Team when needed.
• Acts as a mirror and help Development Team to reflect and

improve as a team
• Acts as Mentor and resolves conflicts when needed

B k
• Coaching the Development Team in organizational environments
in which Scrum is not yet fully adopted and understood.
• Helps Development Team learn Technical practices like

Continuous Integration, Test Automation, Collective Code
Ownership, Refactoring, Test Driven Development, Pair
Programming that will help them deliver high quality
Product Increment every Sprint.
• Helps the Development Team understand the impact of

Technical Debt and ways to manage/minimize
Service to the Product Owner
• Teaches Scrum and ensures that the Product Owner understands

and adheres to Scrum theory, practices and rules
• Helps in Product Owner in ensuring that goals, scope,

priorities and Product Backlog Items are understood by
everyone in the Development Team.
• Helps the Product Owner understand how to create and maintain

Product Backlog efficiently.
• Removes impediments to the Product Owner
• Helps the Product Owner understand how to order/prioritize

Product Backlog items to maximize value.
• Coaches Product Owner in writing clear, concise Product Backlog

items
Service to the Organization
• Working with other ScrumMasters to increase the effectiveness of

Scrum in the organization.

B k
• Coaching organization on Scrum.
• Helping employees, Stakeholders embrace Agile mindset and

implement Scrum.
• Be a Change Agent and create environment, culture of empirical

product development
• Create opportunities for Scrum Teams to share and learn from

each other.
• Helps those outside the Scrum Team understand which

of their interactions with the Scrum Team are helpful and
which are not.
• Help everyone in the Organization change their

interactions with the Scrum Team to maximize the value
created by the Scrum Team.
• Helps Organization understand the impact of

implementing Scrum on Organization Structure/design,
traditional management.
• Helps everyone understand impact of not adopting

Scrum in entirety.

B k
Product Owner:

B k
Product Owner:
• is one person, not a committee or group of people
• Has product vision
• Owns Budget and Responsible for the success of the Product.
• Part of Scrum Team – closely works with the Development Team and
ScrumMaster throughout the Sprint.
• Owns Product Backlog and directs Product development through

Product Backlog prioritization.
• Strives to maximize the value delivered by the Development Team each

Sprint.
• Ensures Product Backlog is visible, transparent and clear to all and shows
what Scrum Team will work on next.
• Ensures Development Team understands Product Backlog Item to the

level needed.
• Accountable for Product Backlog Refinement along with the

Development Team
• Available to the Development Team everyday to answer any queries that

they may have on Product Backlog Items and to provide feedback.
• Has authority to cancel a Sprint
• Accepts/Rejects Development Team work
• Represents Business to the Development Team
• Represents Scrum Team to the Stakeholders

B k
• Interacts with Stakeholders to understand their needs, requests and
create Product Backlog Items to serve them.
• Manages Stakeholder communication and expectations
• Makes decision on when to release the product
• Participates in Scrum Events as needed.
Discuss the following at your table.
Project Manager is NOT a role within Scrum Framework.
• Who is responsible for project management activities in Scrum?
• What happens to the project managers in the organization when

Scrum is introduced?
What happens to specialist roles like Architect, Business Analyst, DBA etc?
What happens if same person is Product Owner and ScrumMaster for a

team?
What happens when same person is Development Team member as well as

ScrumMaster?

B k
Requirements
Source: http://www.slideshare.net/amycslater/requirements-gathering-best-parctice-pack
Walking on Water and developing software from a specification are easy if

both are frozen – Edward V Berard

B k
Product Backlog
Source: https://www.scrumalliance.org/community/articles/2014/december/product-backlog-flows

B k
Product Backlog
 Ordered and Emergent list of features/functionality that might be
needed in the product.
 Product Backlog is dynamic and never complete. Product Backlog exists

as long as the product exists.
 Each Product Backlog Item has an Order, Value, Estimate, and

Description.
 Product Backlog Items are ordered based on Business value, cost of

delay, dependencies, risk.
 Product Backlog Items in the top of the Product Backlog are “small”, well
understood by Team, “Ready” for Development and can deliver value to
Business.
 Product Owner owns Product Backlog and is ultimately responsible for

the contents and state of it.
 Product Owner ensures that Product Backlog is visible, transparent and

clear to all.
 Anyone can add items to the Product Backlog, but Product Owner has
the final authority on whether it stays there.
 Product Backlog is a living artifact. Changes in business requirements,

market conditions, or technology may cause changes in the Product
Backlog.
 1 Product Backlog for 1 Product; Multiple teams working on the same

product uses same Product Backlog.

B k
Product Backlog Refinement
Product Backlog Refinement is an ongoing process in which the Product
Owner and Development Team collaborate on the details of the Product
Backlog items.
Product Backlog Refinement may include
 Adding or removing items to the Product Backlog
 Ordering/Re-ordering items in the Product Backlog
 Estimating Product Backlog Items (PBI)
 Reviewing, Revisiting PBIs.
 Splitting PBIs into smaller PBIs
 Merging PBIs into larger PBIs
The Scrum Team decides how and when refinement is done. Refinement
usually consumes no more than 10% of the capacity of the Development Team.
However, Product Backlog items can be updated at any time by the Product
Owner or at the Product Owner’s discretion.
Product Backlog items that the Development Team may work on in the
upcoming 1-2 Sprints are refined so that any one item can reasonably be
“Done” within the Sprint time-box. Product Backlog items that can be “Done”
by the Development Team within one Sprint are deemed “Ready” for selection
in a Sprint Planning.
Points to Ponder:
How often is the Product Backlog Refinement Done in a Sprint?
What happens if appropriate Product Backlog Refinement is not done?

B k
Why is prioritization important?
Source: https://www.capgemini.com/blog/capping-it-off/2011/03/the-blending-philosophies-of-lean-
and-agile
How many Apps do you have on your Smart Phone? How many of them do
you use every day/month/Year?

B k
User Stories & Acceptance Criteria
3 Cs of a User Story
 Card
 Conversation
 Confirmation (Acceptance Criteria)
Source: http://www.agile-ux.com/2011/04/19/10-strategies-to-split-large-user-stories/

B k
How often should the Sprint Burn Down Chart be updated?
Who should update the Sprint Burn Down Chart?

B k
Definition of Done
List of activities that need to be completed for every PBI to be called complete
and potentially shippable.
It is NOT the acceptance criteria, which is part of a Product Backlog item.

Rather it is a cross functional technical checklist of all the activities the Team
commits to complete for each Product Backlog item.
Definition of Done – Example
Code Review completed Code Checked In

Unit Tests passed Code Refactoring completed
Acceptance Tests passed Automated Regression Tests
passed
Performance Tests passed Integration Tests passed
Security Audit completed Documentation completed
CI Build completed Functionality works on all
Browsers
Supports agreed SLA of 20K transactions per minute
Points to ponder:
When is Definition of Done created? Who creates Definition of Done?
What is impact of weak Definition of Done on Product Quality?
How might a “Definition of Ready” help Scrum Team?

B k
Estimation
Absolute Estimation vs Relative Estimation
Source: http://www.blackpepper.co.uk/agile-vs-waterfall-estimating-planning-tracking/
Estimate the following:
Amount of liquid (in ml) in the glass on your left hand side in the above
picture?
Amount of liquid in the left glass in terms of amount of liquid in the right glass?

B k
Story Point Estimation
Source: https://www.youtube.com/watch?v=sCCUEtjCpCs
 Story Points are unit less and make sense only relatively.
 Story Point != Time
 Development Team does estimation in Scrum. Ultimate goal of

estimating is to gain a shared and better understanding of the items.
Does Scrum prescribe any particular Estimation technique?

B k
Relative Estimation Techniques
Planning Poker:
Source: http://www.agile-ux.com/tag/planning-poker/
T-S hirt Size Estimation:
Source: http://agileupgrade.com/stop-wasting-time-trying-to-get-estimates-right-and-what-to-do-instead/

B k
Sprint Planning
Who: Scrum Team (ScrumMaster, Product Owner, Development Team)
When: At the beginning of the Sprint
Time-Box: Maximum of Eight hours for a one-month Sprint
Input: Product Backlog, latest product increment, Definition of Done, Team

Capacity, Team past performance
Outcome: Sprint Backlog, Sprint Goal, Shared understanding of work that

would be undertaken during the Sprint

B k
Sprint Planning
Sprint Planning answers the following.
 What can be done in the Sprint?
• In the first part of Sprint Planning, the Product Owner presents

ordered Product Backlog items to the Development Team, and the
whole Scrum Team collaborates to understand the work. The
number of Product Backlog items to undertake in the Sprint is
solely up to the Development Team. Neither the Product Owner,
nor any other agency, can push more work onto the Team.
• The Sprint is given a Goal called Sprint Goal. Sprint Goal helps
everyone focus more on the essence of what needs to be done,
and less on small details which may not be important to what we
really need to accomplish.
 How will the chosen work get done?
• In the second part of Sprint Planning, the Development Team

collaborates to decide how to produce the next Product
Increment that meets current Definition of Done.
• Development Team does sufficient design and planning to be

confident of completing the Sprint Goal during the Sprint.
• The Product Owner would remain during this part of the Planning
to answer questions and resolve misunderstandings, if any.
Points to Ponder:
How can you improve the efficiency of the Sprint Planning?

B k
Sprint Backlog
Sprint Backlog is the set of Product Backlog Items selected for the Sprint and a
plan for creating the product increment.
 Sprint Backlog is owned by the Development Team. Only Development

Team can update it during the Sprint.
 Sprint Backlog makes visible all of the work that the Development Team
identifies as necessary to meet the Sprint Goal.
 Development Team uses the Sprint Backlog throughout the Sprint to

manage its progress.
 Sprint Goal is fixed. However, new work/tasks needed to achieve the

Sprint Goal can be added to the Sprint Backlog during the Sprint.
 To ensure continuous improvement, Sprint Backlog included at

least one action item that Scrum Team has agreed upon in
their previous Retrospective meeting.

B k
Daily Scrum
Source: http://geekswithblogs.net/jkhines/archive/2009/06/10/starting-the-sprint.aspx
Daily Scrum is a key inspect and adapt meeting for the Development Team to
synchronize activities and create a plan for the next 24 hours. The Daily
Scrum is held at the same time and place each day to reduce complexity.
The Time-box for Daily Scrum is maximum of 15 minutes.
The structure of the Daily Scrum is set by the Development Team and can be
conducted in different ways with focus on checking the progress towards the
Sprint Goal. Some Development teams uses following questions to check their
progress in Daily Scrum.
• 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?

B k
The Development Team uses the Daily Scrum to inspect progress toward the
Sprint Goal and to inspect how progress is trending toward completing the
work in the Sprint Backlog.

B k
Agree/Disagree?
 TimeBox for Daily Scrum is maximum of 15 minutes.
 Scrum Master ensures that Daily Scrum is done every day.
 Daily Scrum is a meeting to update Status to Scrum Master
 It is okay for Development team members to skip Daily Scrum if they

have no updates to share.
 When Scrum Master is on leave, Daily Scrum should be cancelled on that

day.
 Daily Scrum is held at the same time and place every day.
 It is okay to let Product Owner join Daily Scrum if Development Team

agrees.
 Development Team uses the Daily Scrum to inspect progress toward the
Sprint Goal and to inspect how progress is trending toward completing
the work in the Sprint Backlog.
 Daily Scrums improve communications, eliminate other meetings,

identify impediments to development for removal, highlight and
promote quick decision-making, and improve the Development Team’s
level of knowledge.
At your table, Share details of how Daily Scrum is conducted in your team
and list down at least one improvement you can suggest for your team’s
Daily Scrum.

B k
Is Burn Down chart a Scrum Artifact?
Is it mandatory for Scrum Teams to use Burn Down Chart?

B k
Sprint Review

B k
Sprint Review
Who: Scrum Team and other Stakeholders
When: At the end of the Sprint (Before Sprint Retrospective)
Time-Box: Maximum of 4 Hours for 1 month Sprint (For Shorter Sprints, usually
shorter)
Input: Product Increment, Changes to the Product Backlog during the Sprint
Outcome: Updated Product Backlog, Better understanding of the Product, new

ideas, Release product (if appropriate)
Purpose of Sprint Review is to inspect the increment created in the Sprint and
adapt the Product Backlog if needed.
During the Sprint Review, the Scrum Team and stakeholders collaborate about
what was done in the Sprint. This is an informal meeting, not a status meeting,
and the presentation of the Increment is intended to elicit feedback and foster
collaboration.
During Sprint Review, Scrum Team and Stakeholders also collaborates on what
to do next. So Sprint Review provides valuable inputs to the subsequent Sprint
Planning.

B k
Sprint Retrospective

B k
Sprint Retrospective
Who: Scrum Team
When: At the end of the Sprint (After Sprint Review)
Time-Box: Maximum of 3 Hours for 1 month Sprint (For Shorter Sprints, usually
shorter)
Input: Results from the Sprint, Events that happened during the Sprint
Outcome: Improvements/Action Items that will be implemented in the next

Sprint
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 purpose of Sprint Retrospective is to
• Inspect how the Sprint went with regard to process, tools, people.
• Identify items that went well and potential improvements
• Create Action plan to implement improvements to the way Scrum team

is working
The Scrum Master ensures that the event takes place and that attendants
understand its purpose.

B k
Retrospective Steps
Set the Stage: Setting the stage helps people focus on the purpose of the
Retrospective, reviews the goal of the conversation and creates the space
where the participants feel comfortable discussing the topic at hand.
Gather Data: At this point in the Retrospective we want to develop a shared

understanding of what transpired during the last cycle. It is very important that
everyone’s perspective is given an opportunity to be brought forth and
considered by the entire Team.
Generate Insights: Now is the time to ask “Why?” and begin to examine
alternatives. The goal of this phase is to see the big picture, understand root
causes, consider new possibilities and look for connections between the data
gathered moments ago.
Decide what To Do: As we draw near the end of our time in the Retrospective,
the Team will need to select one or two action items that will make an
improvement in the way they work together. No need to solve world peace
here, just something that will make everyone's day-today experience better.
Close the Retrospective: Provide a clear, crisp ending to the Retrospective and
use this time to ask the Team how to make the next Retrospective better. Be
sure to thank the Team for their efforts during the Retrospective and the
Sprint that just ended.

B k
Myth/Fact:
Time box for Sprint Review is 4 hours for a 1 week
Sprint Review is done before Sprint Retrospective
It is good to invite as many stakeholders as possible to the Sprint Review.
In the Sprint Review, Development Team demos all the work done (including
partially completed Features) during the Sprint.
Scrum Master facilitates Sprint Review when requested.
Product Owner is an optional attendee for Sprint Review.
Scrum Team and Stakeholders attend Sprint Retrospective
Time box for Sprint Retrospective is at most 4 hours for a 4 week Sprint
Core focus of Sprint Retrospective is Process.
Based on the feedback received from Stakeholders in the Sprint Review,

Product Backlog could be updated.
Retrospective is an opportunity to find out team members who did not

perform well and punish them.
Team members can skip Sprint Review if Feature developed by them is not
part of the Sprint Review.
Team can stop doing Sprint Retrospectives if they think they have improved
enough.
Since Team is self-organizing, they can decide on whether to have a Review,

Retrospective or not in any sprint.
Release Burn down is updated in the Sprint Review.

B k
Release Planning
Velocity is the amount of work completed in the Sprint. Consider only
completely Done (100% Done) work for calculating Velocity.
Velocity Calculation:
A Scrum team has started work on a Sprint and planned to complete stories A
and B, estimated at 4 points each, and story C, estimated at 10 points in the
Sprint. At the end of the Sprint, stories A and B are 100% complete but C is
only 80% complete. What is the Velocity of the Team in this Sprint?
In Scrum, Release planning is a simple math!!
Total size of the Product Backlog (in 500

Story Points)
Minimum Velocity 25
Maximum Velocity 50
Average Velocity 40
Based on the data given above, how many Sprints are required to complete
entire Product Backlog?
Point to Discuss:
Who is responsible for managing the scope of the Release?
Who is responsible for updating the Release Burn Chart?
Who is responsible for determining when the product should be released?
Who participates in Release Planning meeting?

B k
Scrum Alliance Certifications

B k
Appendix

B k
Source: http://agilemanifesto.org

B k
Scrum Case Studies
Distributed Scrum Project for Dutch Railways: summary of how a distributed
team (Netherlands and India) successfully executed Scrum after a traditionally
manager project failed to deliver after three years. This case study discussing
topics such as architecture, requirements, documentation and more.
http://www.infoq.com/articles/dutch-railway-scrum
Agile Project Management at Intel – A Scrum Odyssey: detailed case study

describing how Intel used distributed Scrum within a traditional management
culture to reduce cycle time by 66% and eliminate schedule slip within a year.
http://danube.com/docs/case_studies/Intel_case_study.pdf
Agile Case Study – H&R Block: short summary of how one company helped a
very traditional, time-sensitive, consumer tax preparation service transform
their business using Scrum. The real value in this case study are the links to
the high-quality, short video testimonials from the participants to explain the
benefits of Scrum.
http://braintrustgroup.com/case-studies/agile-case-study/
Scrum Boosts Effectiveness at the BBC: this thirty-eight minute video

presentation, the Head of Development of the BBC’s New Media Division
discusses their multi-year journey to effectively use Scrum.
http://www.infoq.com/presentations/Scrum-bbc-newmedia
Effects of Scrum Nine Months Later: case study author, Richard Bank,
identifies the lasting benefits of Scrum after a disastrous, piecemeal
introduction of Scrum. Be sure to read his candid assessment of how he failed.
http://www.infoq.com/news/2006/11/scrum-9-months-later
Effective Practices and Federal Challenges in Applying Agile Methods: the

Government Accountability Office (GAO) provides a review of the challenges
and success factors for Agile projects within the federal government based on
their investigation of four successful programs.
B k
http://www.gao.gov/assets/600/593091.pdf
Adobe Premiere Pro Scrum Adoption: Adobe explains how they used Scrum to
successfully coordinate the actions of a distributed Scrum Team within an
environment composed of non-Scrum Teams.
http://blogs.adobe.com/agile/files/2012/08/Adobe-Premiere-Pro-Scrum-
Adoption-How-an-agile-approach-enabled-success-in-a-hyper-competitive-
landscape-.pdf
Rolling Out Agile in a Large Enterprise: this case study from 2006 discusses
how Yahoo! used Scrum to support over 100 software teams. Provides
interesting metrics on how to evaluate and monitor Scrum Teams in a large
enterprise.
http://www.controlchaos.com/storage/scrum-
articles/YahooAgileRollout.pdf
Borland’s Agile Journey – A Case Study in Enterprise Transformation: in this

2009 case study, the Vice President of Product Development at Borland talks
about benefits they received and the key lessons learned in their three-year
journey to apply Scrum to their business.
http://www.agileconnection.com/article/enterprise-agile-journey
Business Analysts and Scrum Projects: short description of how a business

analyst’s role changes when they are embedded full time on a cross-functional
Scrum Team.
http://www.boost.co.nz/blog/2012/01/business-analysts-and-scrum-
projects-a-short-case-study/
My Experience as QA in Scrum: detailed experience report of the day-to-day

activities of a tester on a Scrum Team.
http://www.infoq.com/articles/experience-qa-scrum

B k
Moving Back to Scrum and Scaling to Scrum of Scrum in Less Than a Year: this
fifteen-minute video presentation explains how one Brazilian company
struggled with Scrum, failed and then eventually succeeded.
http://www.infoq.com/presentations/Moving-Back-to-Scrum
Successful Leadership with Scrum: short discussion identifying some early

steps needed to gain buy-in about Scrum from senior level managers before
starting your first Scrum Team.
http://p-a-m.org/2010/11/successful-leadership-with-scrum-a-case-study/
A CIO’s Playbook for Adopting the Scrum Method of Achieving Software

Agility: this 28-page whitepaper from 2005 describes step-by-step how Ken
Schwaber envisioned a Scrum business transformation might unfold.
http://www.torak.com/sites/default/files/files/CIO%20Playbook%20For%20
Adopting%20Scrum.pdf
Source: http://lookforwardconsulting.com

B k
Reading references:
• Succeeding with Agile - Software Development Using Scrum by Mike
Cohn
• Agile Retrospectives by Esther Derby and Diana Larsen
• Agile Estimating and Planning by Mike Cohn
• User Stories Applied for Agile Software Development by Mike Cohn
• Agile Software Development Ecosystems by Jim Highsmith
• Agile Project Management with Scrum by Ken Schwaber
• http:ScumAllaince.org
• http:AgileManifesto.org
• http://www.scrumguides.org
• www.mountaingoatsoftware.com/scrum
• http://less.works

B k
An Example Checklist for ScrumMasters
Michael James
(mj4scrum@gmail.com)
14 September 2007
(Revised 24 July 2012)
A Full Time Facilitator?

An adequate ScrumMaster can handle two or three teams at a time. If you're content to limit your role to
organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report, you can
get by with part time attention to this role. The team will probably still exceed the baseline, pre-Scrum expectation
at your organization, and probably nothing catastrophic will happen.
But if you can envision a team that has a great time accomplishing things no one previously thought possible,
within a transformed organization, consider being a great ScrumMaster.
A great ScrumMaster can handle one team at a time.
We recommend one dedicated ScrumMaster per team of about seven, especially when starting out.
If you haven't discovered all the work there is to do, tune in to your Product Owner, your team, your team's
engineering practices, and the organization outside your team. While there's no single prescription for everyone,
I've outlined typical things I've seen ScrumMasters overlook. Please mark each box with √, ∆, ?, or N/A, as
described on the last page.
Part I -- How Is My Product Owner Doing?

ScrumMasters improve Product Owner effectiveness by helping them find ways to maintain the Product Backlog
and release plan. (Note that only the Product Owner may prioritize the backlog.)
☐ Is the Product Backlog prioritized according to his/her latest thinking?

☐ Are requirements and desirements from all stakeholders captured in the Product Backlog? Remember: the
backlog is emergent.
☐ Is the Product Backlog a manageable size? To maintain a manageable number of items, keep things more
granular towards the top, with general epics at the bottom. It's counterproductive to overanalyze too far past
the top of the Product Backlog. Your requirements will change in an ongoing conversation between the
developing product and the stakeholders/customers.
☐ Could any requirements (especially those near the top of the Product Backlog) be better expressed as
independent, negotiable, valuable, estimable, small, and testable user stories1 ?
☐ Have you educated your Product Owner about technical debt and how to avoid it? One piece of the puzzle
may be to write automated test and refactoring into the definition of "done" for each backlog item.
☐ Is the backlog an information radiator, immediately visible to all stakeholders?

☐ IfAutomated
you're using an automated tool for backlog management, does everyone know how to use it easily?
management tools introduce the danger of becoming information refrigerators without active
radiation from the ScrumMaster.
1 http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
Copyright © 2007-2012 Michael James. All Rights Reserved.

☐ Can you help radiate information by showing everyone printouts?
☐ Can you help radiate information by creating big visible charts?
☐ Have you helped your Product Owner organize backlog items into appropriate releases or priority groups?
☐ Does everyone know whether the release plan still matches reality? You might try showing everyone Product/
Release Burndown Charts2 after the items have been acknowledged as “done” during every Sprint Review
Meeting. Charts showing both the rate of PBIs actually completed and new ones added allow early discovery
of scope/schedule drift.
☐ Did your Product Owner adjust the release plan after the last Sprint Review Meeting? The minority of Product
Owners who ship adequately tested products on time re-plan the release every Sprint. This probably requires
deferring some work for future releases as more important work is discovered.
Part II -- How Is My Team Doing?
While you are encouraged to lead by the example of collaborating with team members on their work, there is a
risk you will get lost in technical tasks. Consider your primary responsibilities to the team:
☐ Is your team in the state of flow? Some characteristics of this state :

3
• Clear goals (expectations and rules are discernible and goals are attainable, aligning appropriately with
one's skill set and abilities).
• Concentration and focus, a high degree of concentration on a limited field of attention.
• A loss of the feeling of self-consciousness, the merging of action and awareness.
• Direct and immediate feedback (successes and failures in the course of the activity are apparent, so that
behavior can be adjusted as needed).
• Balance between ability level and challenge (the activity is neither too easy nor too difficult).
• A sense of personal control over the situation or activity.
• The activity is intrinsically rewarding, so there is an effortlessness of action.
☐ Do team members seem to like each other, goof off together, and celebrate each other's success?
☐ Do team members hold each other accountable to high standards, and challenge each other to grow?
☐ Are there issues/opportunities the team isn't discussing because they're too uncomfortable?
4
☐ Have you tried a variety of formats and locations for Sprint Retrospective Meetings?
5
☐ Has the team kept focus on Sprint goals? Perhaps you should conduct a mid-Sprint checkup to re-review the
acceptance criteria of the Product Backlog Items committed for this Sprint.
2 Mike Cohn, Agile Estimation and Planning. (2005).
3 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).
4Kerry Patterson, Crucial Conversations: Tools for Talking When Stakes are High (2002). Also consider enlisting a
professional facilitator who can make uncomfortable conversations more comfortable.
5 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).

☐ Does the Sprint taskboard reflect what the team is actually doing? Beware the “dark matter” of undisclosed
tasks and tasks bigger than one day’s work. Tasks not related to Sprint commitments are impediments to
those commitments.
☐ Does your team have 3-9 people with a sufficient mix of skills to build a potentially shippable product
increment?
☐ Is your team's taskboard up to date?

☐ Are the team self-management artifacts (taskboard, Sprint Burndown Chart, impediments list, etc.) visible to
the team, convenient for the team to use?
☐ Are these artifacts adequately protected from meddlers? Excess scrutiny of daily activity by people outside
the team may impede team internal transparency and self management.
☐ Do team members volunteer for tasks?

☐ Has the need for technical debt repayment been made explicit in the backlog items, gradually making the
code a more pleasant place to work?
☐ Are team members leaving their job titles at the door of the team room, collectively responsible for all aspects
of agreed work (testing, user documentation, etc.)?
Part III -- How Are Our Engineering Practices Doing?
☐ Does your system in development have a "push to test" button allowing anyone (same team or different team)
to conveniently detect when they've caused a regression failure (broken previously-working functionality)?
Typically this is achieved through the xUnit framework (JUnit, NUnit, etc.).
☐ Do you have an appropriate balance of automated end-to-end system tests (a.k.a. "functional tests") and
automated unit tests?
☐ Is the team writing both system tests and unit tests in the same language as the system they're developing?
Collaboration is not enhanced by proprietary scripting languages or capture playback tools that only a subset
of the team knows how to maintain.
☐ Has your team discovered the useful gray area between system tests and unit tests ?
6
☐ Does a continuous integration server automatically sound an alarm when someone causes a regression
7
failure? Can this feedback loop be reduced to hours or minutes? ("Daily builds are for wimps." -- Kent Beck)
☐ Do all tests roll up into the continuous integration server result?

☐ Have team members discovered the joy of continuous design and constant refactoring , as an alternative to
8
Big Up Front Design? Refactoring has a strict definition: changing internal structure without changing external
behavior. Refactoring should occur several times per hour, whenever there is duplicate code, complex
conditional logic (visible by excess indenting or long methods), poorly named identifiers, excessive coupling
between objects, etc. Refactoring with confidence is only possible with automated test coverage. Neglecting
6 http://blogs.collab.net/agile/2007/03/07/junit-is-not-just-for-unit-testing-anymore/
7 http://www.martinfowler.com/articles/continuousIntegration.html
8 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).

refactoring makes it hard to change the product in the future, especially since it’s hard to find good developers
willing to work on bad code.
☐ Does your definition of "done" for each Product Backlog Item include full automated test coverage and
refactoring? Learning Test Driven Development (TDD) increases the probability of achieving this.
☐ Are team members pair programming most of the time? Pair programming may dramatically increase code
maintainability and reduce bug rates. It challenges people's boundaries and sometimes seems to take longer
(if we measure by lines of code rather than shippable functionality). Lead by example by initiating paired
workdays with team members. Some of them will start to prefer working this way.
Part IV -- How Is The Organization Doing?
☐ Is the appropriate amount of inter-team communication happening? “Scrum of Scrums” is only one way to
achieve this, and not necessarily the best.
☐ Are teams independently able to produce working features, even spanning architectural boundaries?
9
☐ Are your ScrumMasters meeting with each other, working the organizational impediments list?
☐ When appropriate, are the organizational impediments pasted to the wall of the development director's office?
Can the cost be quantified in dollars, lost time to market, lost quality, or lost customer opportunities? (But
learn from Ken Schwaber's mistakes: "A dead ScrumMaster is a useless ScrumMaster." 10)
☐ Is your organization one of the few with career paths compatible with the collective goals of your teams?
Answer "no" if there's a career incentive 11 to do programming or architecture work at the expense of testing,
test automation, or user documentation.
☐ Has your organization been recognized by the trade press or other independent sources as one of the best
places to work, or a leader in your industry?
☐ Are you creating a learning organization?
Conclusion
If you can check off most of these items and still have time left during the day, I’d like to hear from you.
There’s no canned formula for creating human ingenuity. This paper lists points which may, or may not, help in
your situation.
Once you start to realize what you could do to make a difference, you may find yourself afraid to do it. This is a
sign you're on the right track.
9 http://FeatureTeamPrimer.org/
10 Ken Schwaber, Agile Project Management with Scrum (2004)
11 Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (1999)

Scrum Training –Quiz
1. Which of the following is an Agile Manifesto Value?
a. Individuals and Interactions over contract negotiation

b. Responding to change over following a plan
c. Customer Collaboration over comprehensive documentation
d. Working software over process and tools
2. Which of the following is NOT an Agile Manifesto Principle?
a. Simplicity—the art of maximizing the amount of work not done—is essential

b. Business people and developers must work together daily throughout the project
c. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done
d. Status Report is the primary measure of progress
3. Which of the following is NOT a Scrum value?
a. Focus
b. Openness
c. Fun
d. Courage
4. The pillars or attributes of Empiricism are:
a. Transparency, Inspection, Adaptation

b. Plan, Do, Check, Act
c. Fun, Honesty, Openness
d. Focus, Commitment, Respect
5. What does incremental deliverymean?
a. Team release working software to the testing team at the end of each sprint
b. Team deliver non functional increments before every sprint review
c. Team improves and elaborates agile process with each increment delivered
d. Team deploys functional increments of the product over the course of the project
6. Which of the following is NOT a scrum role?
a. Project Manager
b. Product Owner
c. ScrumMaster
d. Development Team
Copyright 2014 – 2017 Narasimha Reddy Bommaka

7. Which of the following is NOT one of the responsibilities of the Scrum Master?
a. Helping team to self organize

b. Helping organization, team learn about Scrum
c. Updating Sprint Burn Down chart
d. Facilitating the meetings in Scrum
8. Who is responsible for the Quality of the Product being developed?
a. Testing Group/Specialist
b. Scrum Master
c. Team
d. Product Owner
9. Which of the following is NOT one of the responsibilities of the Product Owner?
a. Maximizing the Business value

b. Prioritizing Product Backlog items
c. Making sure that team participates in Daily Scrum meeting everyday
d. Participates in Sprint Planning meeting
10. Ideal size of the Team in Scrum is Mark only one oval.
a. Team size does not matter

b. 3 to 9
c. 10 to 20 people
d. No more than 50
11. Which of the following is NOT one of the responsibilities of the Team?
a. The Team selects how much work they can do in a Sprint

b. The Team tracks work progress in a Sprint
c. The team prioritizes Product Backlog items in the Product Backlog
d. The team updates the Task Board to show the correct status of the work in progress
12. In Scrum, Who is responsible for helping team and organization learn Scrum?
a. Project Manager
b. Scrum Master
c. Product Owner
d. Learning and Development Team
13. Who owns Sprint Backlog?
a. The Team
b. Product Owner
c. Scrum Master
d. Scrum Team

14. You are in the middle of a sprint. Your VP walks over to the Development Team and tells
that he needs a new feature (not taken up during sprint planning) by the end of the current
sprint. What should the Scrum Master do?
a. Demand team to Pick up the features for the current sprint since Agile is all about
customer collaboration
b. Ask the Development Team to take on that feature, but drop an equivalent feature from
their Sprint Backlog
c. The VP is a powerful guy, talk to the Product Owner to terminate the Sprint and restart
the Sprint to accommodate his request
d. Ask the VP to talk to the Product Owner as he/she owns the Product Backlog
15. Which of the following is NOT a ceremony in Scrum?
a. Sprint Planning
b. Sprint Review
c. Sprint Retrospective
d. Monthly Project Status Update meeting
16. What is expected at the end of the Sprint Planning meeting?
a. Sprint Goal & Sprint Backlog

b. Sprint Backlog with Tasks and Resource assignments
c. Updated Project Plan
d. Individual Task Assignment and Goal for each Team member
17. Which of the following may be used as a tool to track progress of a Sprint by the team?
a. A task board
b. Release Plan
c. User Stories in the Product backlog
d. WBS
18. The Primary purpose of a Sprint Burn-down chart is
a. To help see the amount of work completed in a Sprint

b. To help see the amount of work remaining in a Sprint
c. To help the Product Owner to see if the team will meet the release date
d. To help Scrum Master assess the performance of each team member
19. Which of the following is NOT true about Sprint?
a. Sprint is a time-box of one month or less

b. Sprint is a fixed period of time
c. The length of the Sprint changes from Sprint to Sprint to accommodate large user stories
d. The team aims to deliver potentially shippable product increment in every Sprint

20. Why should the Scrum Master attend Daily Scrum?
a. To ask the 3 questions and get answers from each team member
b. Scrum Master need not attend it. Just have to ensure that the team has a Daily Scrum
c. To ensure that the task board and burn charts (burn up/ burn down charts) are updated
d. To ensure that the team members stick to the Daily Scrum time-box
21. The Definition of Done
a. Explains the functionality of a feature (What), who will use the feature (Who) and the
benefit that person will get by using that feature (Why)
b. A “to-do” list given to the Development Team by the Product Owner
c. Is a checklist of all the items that has to be completed for each Product Backlog Item so
that the resulting Product Increment is potentially releasable
d. Different for each User Story in the Product Backlog
22. Sprint completes when
a. Product Owner says so

b. all the sprint backlog items are complete
c. Timebox expires
d. Team members get tired
23. Sprint Goal can change during Sprint
a. True
b. False
24. What is the duration of Sprint Planning if the Sprint is one week long?
a. 4 hours
b. <= 2 hours
c. 2 hours
d. <= 4 hours
25. There were 6 people in your Development Team. Due to lack of specific skills, on Product
Owner’s request, Management adds 3 more people to Development Team. How long
should Daily Scrum be?
a. Daily Scrum will not work for a large team. Cancel Daily Scrum
b. 30 minutes, 15 minutes in the morning and 15 minutes in the evening. With this everyone
gets a chance to talk
c. The duration increases proportionately as there are more team members
d. 15 minutes. Because the stand-up is time-boxed to 15 minutes regardless of the number
of members in the team

26. Who is responsible for turning the Product Backlog Items into a Product Increment?
a. Scrum Team
b. Team
c. Product Owner
d. Scrum Master
27. During the Daily Scrum meeting, Sreedhar mentions that he found a plugin that can be
used to complete the work quickly. What should the Team do now during the Daily Scrum?
a. Discuss how the plugin can be used

b. Other team members update how they are working towards achieving the Sprint Goal
and if they are faceing with any impediments
c. Discuss challenges in using the plugin
d. Extend the Daily Scrum to train all team members on how to use the plugin
28. What is the Sprint Goal for Sprint-0?
a. Set up infrastructure and do Product Discovery

b. It is a practice sprint for the Team
c. Show management how Sprints work
d. There is no such thing as Sprint-0. Every spring should deliver a Product Increment
29. The Daily Scrum meeting is
a. A status meeting for the Product Owner, Scrum Master and any other stakeholder who
wants to know how the team is progressing
b. Something which the Team can decide if they want to have it/not have it
c. Mandatory
d. Optional, as long as everyone knows what’s happening with the team
30. Who can terminate the sprint?
a. The Product Owner

b. The Development Team member, when they realize that the Sprint Goal cannot be
achieved
c. The Scrum Master, in the absence of Product Owner
d. The Agile Project Manager
31. When is testing done? And by Whom?
a. During a Testing Sprint, done by the Testing Team

b. During the Hardening Sprint, done by the Development Team
c. Before the Sprint concludes, mostly at the end of the sprint, by the QA person in the team
d. Throughout the Sprint by, everyone in the Development Team

32. During Daily Scrum, you observe that the team exceeds the allocated time-box. Not
everyone has spoken yet. What should you do?
a. Terminate the Daily Scrum

b. Wait for everyone to complete
c. After the time-box, tell the team that the time-box is over and ask them what they want to
do now.
d. The Team is self-organizing, they will figure it out.
33. Should the Product Owner attend Daily Scrum?
a. The Product Owner should not attend it as Daily Scrum is for the Development Team
b. The Product Owner is optional, and the Product Owner decides if he/she should attend
Daily Scrum
c. Product Owner is part of the Scrum Team and so should attend it every day
d. The Product Owner is optional, and the Dev Team decides if PO should attend their Daily
Scrum
34. Who should be responsible for writing the user stories/Product Backlog Items?
a. Product Owner
b. Scrum Master
c. Team
d. It does not matter who writes it, but Product Owner is ultimately responsible for the
Backlog
35. Who should update the Development Team’s visual information radiators?
a. Scrum Master
b. Any of the Development Team member can update it
c. Team Lead
d. The junior most member of the team should update it, it is an unsaid rule
36. Who is responsible for architecture of the product being developed by the Development
Team?
a. The Team
b. The designated architect chosen by the Scrum Team
c. It does not matter as long as the architecture is designed upfront and given to the
development team
d. Architecture Team
37. The Scrum Artifacts include
a. Sprint Goal, Task Board, Definition of Done

b. User Stories, Velocity, Product Backlog
c. Product Backlog, Sprint Backlog, Increment
d. Sprint Burn Down Chart, Task Board, Estimates

38. Sukesh is the Scrum Master for his team. The Product Owner moved on to take a different
job and Sukesh's team now does not have a PO. Sukesh was the BA before and knows the
product well, and now is asked to be a PO and a Scrum Master for the team. Can he be a
PO and Scrum master for the same team?
a. No, Sukesh will end up working a lot and is not sustainable

b. No, because Sukesh will have too much power and will create confusion
c. Yes, because there is no one else to take on those responsibilities
d. Yes, that would make perfect sense for the Team and the organization, just one point of
contact
39. How does the Team decide whether a Product Backlog item is done?
a. When the Sprint timebox has ended

b. When the Product increment meets the current Definition of Done
c. When Scrum Master agrees that the Product Backlog item is done
d. When tester has signed off the increment after testing
40. A Product Backlog is
a. A prioritized list of tasks to realize the business/product needs. The Development Team
is responsible for creating and managing this list
b. A list of detailed functional and non-functional requirements. The Product Owner is
responsible for creating and managing this list.
c. A list of detailed functional and non-functional requirements that the team has determined
that it will not complete in the Sprint.
d. A prioritized list of functional and non-functional business needs. The Product Owner is
responsible for creating and managing this list.
41. What is the purpose of a sprint review meeting?
a. A formal meeting where the product is presented to everyone.

b. To reflect what went well (on how they work), what did not go well, and what the team
should try different during the next sprint
c. The cross functional, self-organizing team discusses the changes (both product wise and
process wise) which the team should incorporate so as to function more efficiently
d. The Team and the stakeholders collaborate about what was done in the sprint. Based on
that and any changes to the product backlog, the attendees collaborate on next things
that could be done. The informal presentation is intended to elicit feedback and foster
collaboration
42. The Sprint Retrospective meeting is
a. A meeting that follows Sprint Review meeting where the team reflects on the Sprint to
improve their process.
b. A meeting that follows Sprint Review meeting where the Project Manager collects lesson
learned so that it can be documented in the process audit documentation.

c. A meeting at the end of every Sprint where the team demonstrates the product increment
that they created in order to get feedback from the stakeholders. Anyone interested in the
product is invited to this meeting.
d. A meeting at the end of every Sprint where the team reviews the past Sprint for lessons
learned. Only the core team members are invited to this meeting.
43. The team has targeted to complete Story A, B, C with story Points 3,7,11 respectively in a
Sprint. However, at the end of the Sprint, team was able to complete only Stroy A, B and
90% of Stroy C. What is the velocity of this team in this Sprint?
a. 21
b. 19.9
c. 18.9
d. 10
44. During the sprint, the Development Team feels that they will not be able to complete all the
work as per Definition of Done. What should the Development Team do first?
a. Terminate the sprint and start a new sprint which is longer than the previous one
b. Work from the top and complete as much as possible to maximize value delivery.
c. Raise it as an impediment to Scrum Master
d. Collaborate with the Product Owner and renegotiate the scope of the sprint
45. The team Velocity is located in Hyderabad, India and Product Owner of this team is in
Texas, US. Where would you advice Scrum Master to be located?
a. In Hyderabad, India with the Team

b. In Texas, US with the Product Owner
c. In a beach resort in Europe
d. It doesnt matter where Scrum Master would be located.
46. The Velocity of Team Velocity is 100 and the velocity of Team Gordzilla is 15. Senior
manager Narayan is concerned that team Gordzilla's productivity is less than 20% of that
of Team Velocity. As a Scrum Master, What would you advice Narayan to do in this
scenario?
a. Velocity of Team Gordzilla is not acceptable. Ask Narayan to punish this team.
b. Swap some team members in Team Gordzilla with some members of Team velocity so
that there will be some high performing members in the Team Gordzilla
c. Send Team Gordzilla to Technical trainings since they seem be slow at their work.
d. Inform Narayan that Velocity cannot be used to measure Productivity of team and help
him understand the concept of Story Points.

StarAgile CSM ParticipantWorkBook 2017

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

StarAgile CSM ParticipantWorkBook 2017

Uploaded by

Copyright:

Available Formats

Name :

Narasimha Reddy Bommaka

Copyright 2017 – 2020 Narasimha Reddy 2

Copyright 2017 – 2020 Narasimha Reddy 3

Copyright 2017 – 2020 Narasimha Reddy 4

DEFINED PROCESS -> CONTROLLED & COORDINATED

Copyright 2017 – 2020 Narasimha Reddy 5

Copyright 2017 – 2020 Narasimha Reddy 6

Developing a system through repeated cycles (iterative) and in smaller

Copyright 2017 – 2020 Narasimha Reddy 7

Copyright 2017 – 2020 Narasimha Reddy 8

Copyright 2017 – 2020 Narasimha Reddy 9

over processes and tools

over comprehensive documentation

over contract negotiation

over following a plan.

2. Welcome changing requirements, even late in development. Agile

3. Deliver working software frequently, from a couple of weeks to a couple of

5. Build projects around motivated individuals. Give them the environment

6. The most efficient and effective method of conveying information to and

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors,

9. Continuous attention to technical excellence and good design enhances

10. Simplicity—the art of maximizing the amount of work not done—is

Copyright 2017 – 2020 Narasimha Reddy 11

Copyright 2017 – 2020 Narasimha Reddy 12

Copyright 2017 – 2020 Narasimha Reddy 13

Scrum is founded on empiricism and the three pillars of empiricism are

Questions to ponder over with someone in the class:

Copyright 2017 – 2020 Narasimha Reddy 14

Copyright 2017 – 2020 Narasimha Reddy 15

During Sprint, Scrum team works together to create a potentially shippable

 Sprint enables predictability

 Sprint limits risk

 Sprint duration should be consistent throughout the development effort

 Sprint ends only when time-box expires

Factors influencing the duration of Sprint:

In Scrum, all events are time-boxed.

Copyright 2017 – 2020 Narasimha Reddy 16

What is the purpose of a Sprint Burn Down Chart?

What do you measure in a Sprint Burn Down Chart?

What is the Velocity of this Sprint?

Copyright 2017 – 2020 Narasimha Reddy 17

At the end of each Sprint, update the release burn up chart.

Copyright 2017 – 2020 Narasimha Reddy 18

Copyright 2017 – 2020 Narasimha Reddy 19

Copyright 2017 – 2020 Narasimha Reddy 20

• Primary responsibility of the Development Team is to deliver a

• Self-Organizing -> empowered to manage, organize their own work to

• Cross-functional -> Have all the skills necessary as a team to create a

• Responsible for the Quality and Design of the product.

• No silos (sub-groups) and no appointed leaders in the Team.

• Ideally co-located and have fully committed/allocated to the project.

• Individuals in the team may have specialized skills, but accountability

• Participates in all Scrum Events – Sprint Planning, Daily Scrum, Sprint

• Updates Sprint Burn-Down charts and Task boards

• Estimates items in the Product Backlog

• Helps Product owner in Product Backlog Refinement

Copyright 2017 – 2020 Narasimha Reddy 21

Copyright 2017 – 2020 Narasimha Reddy 22

Copyright 2017 – 2020 Narasimha Reddy 23

• Not a manager (Cannot make decisions on behalf of the Team or Product