This simple and crisp quick reference card is for Agile and Scrum basics. It is a simple way to glance through all the concepts and use it as a tool for revision, even before an interview.

1. Agile
SCRUM– Roles, Artifacts, Meetings, Tools, Glossary
Quick Reference Cards
+9122 4015 5175 +9122 2570 2772 +9122 2857 4960
http://www.techcanvass.com/
Copyrights @ Techcanvass | all rights reserved
Owns the Software
Scrum Team figures out how to turn the Product Backlog into an
increment of functionality within a Sprint. Each team member is
jointly responsible for the success of each iteration and of the
project as a whole.
• Team is cross functional ( Business Analyst, developer tester)
• Team consists of 3-12 full time members ( Exceptions : Specific
roles DBA)
• Self-organizing and self-managing team
• Maintains the Sprint Backlog
• Conducts the Sprint Review
• Technical implementation of User Stories
• Delivers a “potentially shippable” product increment at every
Sprint
Manifesto for Agile
Roles - Product Owner (PO)
Owns the Product Backlog
Product Owner represents the interests of project Stakeholders
and is responsible for the final product
• Elicitation of product requirements and features
• Responsible for prioritizing of requirements
• Owns the Product Backlog
• Manage the Release Plan
• Manage the Return on Investment
• Accountable for product success
Individuals and interactions
over processes and tools
Working software
over comprehensive documentation
Customer collaboration
over contract negotiation
Responding to change
over following a plan
Dynamic prioritized list of requirements
• Product backlog is dynamically prioritized list of requirements
ordered by Business Value
• Requirements can be added by anyone at anytime
• PBL can contain bugs and non-functional items
• Requirements are broken down into User Stories by Product
Owner
• Prioritize the requirements based on Business Value
Artifacts - Product Backlog (PBL)
Owns the Scrum process
Scrum Master is responsible for the Scrum process. He ensures
everybody plays by the rules. The Scrum Master is not part of the
Team.
• Manage the Scrum process
• Remove impediments for the Team
• Facilitate communication
• Is a facilitator and not a manager
• Shields the team from external interference
Roles – Scrum Team
1. Satisfy the customer through early and continuous delivery
2. Welcome changing requirements, even late in development
3. Deliver working software frequently
4. Business people and developers work together daily
5. Build projects around motivated individuals
6. Convey information via face-to-face conversation
7. Working software is the primary measure of progress
8. Maintain a constant pace indefinitely
9. Give continuous attention to technical excellence
10. Simplify: maximize the amount of work not done
11. Teams self-organize
12. Teams retrospect and tune their behaviors
Meetings – Sprint Planning
To commit the deliverable(s) to the PO
PBL prepared prior to meeting. It’s a two part meeting:
• PO presents the User Stories
• Team selects items committing to complete
• Discussion on PBI for clarifications
• Creation of Sprint Backlog from PBL
• Team solely responsible for deciding how to build
• Breakdown of user stories in Tasks to fill the SBL (normally 3 to 4
days of work, than inspect & adapt)
• PO available for questions
Timebox: 4 hours
Owner: Product Owner
Participants: Scrum Master, Scrum Team
Displays the remaining work
• Burndown chart shows the amount of work remaining per Sprint
• It is a very useful way of visualizing the correlation between work
remaining at any point in time and the progress of the Team(s)
• Use a tool e.g. JIRA for auto creation of the Burndown Chart
To Inspect and Adapt the progress
In this standup meeting the Team daily inspects their progress in
relation to the Planning by using the Burndown Chart, and makes
adaptation as necessary.
• Held every day during a Sprint (same time & place)
• Team members report to each other and not to SM
• Ask 3 questions during meeting:
"What have you done since last daily scrum?"
"What will you do before the next daily scrum?"
"What obstacles are impeding your work?“
Timebox: 15 minutes
Owner: Scrum Master
Participants: Team, all interested parties may silently attend
To maintain the good, get rid of the bad
At the end of a Sprint, the Team evaluates the finished Sprint.
• What went well and what can be improved
• Capture positive ways as a best practice, identify challenges and
develop strategies for improvements.
• SM helps team in discovery & not provide answers
Timebox: 3 hours
Owner: Scrum Master
Participants: Team, (Product Owner)
To demonstrate the achievements
The team present product owner the result on the developed
product of the Sprint. Product owner can accept or reject features
depending on the agreed acceptance criteria.
Timebox: 4 hours
Owner: Team
Participants: Scrum Master, Product Owner, optionally the PO can
invite other Stakeholders
Meetings - Daily Scrum
Meetings - Sprint Review
Artifact - Burndown Chart
Visibility + Flexibility = “Scrum”
“Done” = Potentially Shippable
Scrum requires at the end of each Sprint that the product is
production ready. That means the increment is:
• Thoroughly tested and stable
• Well-structured
• Well-written code
• User operation of the functionality is documented
Artifacts - Potentially Shippable Product
List of Tasks to fulfill the Sprint Goal
• Sprint Backlog contains all the committed User Stories for the
current Sprint broken down into Tasks by the Team
• All items on the Sprint Backlog should be developed, tested,
documented and integrated in order to fulfill the Sprint Goal.
• Estimate Story complexity using Planning Poker
Artifacts - Sprint Backlog (SBL)
12 Principles of Agile Development
Roles - Scrum Master (SM)
Meetings – Retrospective

2. Agile
SCRUM– Roles, Artifacts, Meetings, Tools, Glossary +9122 4015 5175 +9122 2570 2772 +9122 2857 4960
http://www.techcanvass.com/
Copyrights @ Techcanvass | all rights reservedQuick Reference Cards
Set of values as the foundation for the team's processes and
interactions
Commitment towards team and Sprint Goal
Focus being focused on the sprint and its goal
Openness to highlighting when you have challenges and
problems that are stopping you from success
Respect helping people to learn the things that you are good at
and not judging situations and people
Courage to being transparent, but willing to change even if that
means accepting that you are wrong
Scrum / Task Board
• Board containing teams Sprint goals, backlog items, tasks, tasks
in progress, "DONE" items and daily Sprint Burndown chart
• Scrum meetings best held around task board
• Visible to everyone
Free online Agile tools: Icescrum , Taiga , Scrumpy, Hansoft,
scrumdesk ,YouTrack , JIRA, VersionOne and scrumdo
Tools – Scrum Board
5 Scrum Values
Inspection
Timely checks on the process and artifacts towards Sprint Goal
to detect undesirable variances
Adaptation
Adjusting a process as soon as possible to minimize any further
deviation or issues
3 pillars in SCRUM
SCRUM uses an empirical approach
in order to adapt to the changing
requirements of the customer
Transparency
Viewed in the form of Product
Backlog, Task Boards and Burndown
charts, Daily Stand-ups,
Retrospectives, Sprint Reviews
Empirical Process in SCRUM
Make SMART Requirements: Simple, Measurable, Achievable,
Realistic, Traceable.
User Stories
A very high level definition of what the customer wants the
system to do. Each story is captured as a separate item on the
PBL
User Story Template:
As a <user> I want <function> So that <desired result>
INVEST in User Stores:
• Independent
• Negotiable
• Valuable
• Estimable
• Small
• Testable
Tasks
Make sure a Task is TECH. Time boxed, Everybody (can pick it up),
Complete and Human-readable
Requirements – User Stories & Tasks
Epic: A very large user story that is eventually split up into
multiple related user stories
Timebox: Fixed time period which cannot be exceeded
Scrum: Most widely used agile framework comprising of short
iterations, called sprints. Actual work is done within sprints
Sprint: Sprint is the scrum term for an iteration
Task: A completely broken down form of a user story
Spike: A short, time-boxed piece of research, usually technical,
on a single story that is intended to provide just enough
information that team can estimate the size of story
Definition of “Done” (DoD): List of development activities
required to consider an increment of functionality as “Done”.
Velocity: Rate at which team converts items to “DONE” in a
single Sprint. It is usually calculated in Story Points
Poker Planning: Consensus based approach for estimating
the efforts for a task. Generally involves team members and POs
proposing estimation values using poker cards and then finally
everyone agreeing to one value
Impediment: Anything which slows the team down or
prevents someone from working
Technical Debt: A consequence of poor engineering practices
which make a program difficult to modify. Technical bankruptcy
follows: Throw the program away and write a new one
Is Scrum agile?
Yes. Scrum is agile, but agile is more than Scrum.
Scrum signs up to all of the values and principles in the Agile
Manifesto and so is one member of the agile family along with
eXtreme Programming (XP), Kanban, Lean software
development, Crystal, and even hybrids such as Scrumban.
Who is responsible for managing the teams?
Teams are responsible for managing themselves
What is the effort/duration of a task?
Tasks should take no longer than 16 hours. If longer then the
task should be broken down further
Who manages obstacles?
Primary responsibility of managing obstacles is on the Scrum
Master. However, teams must learn to resolve their own issues.
Two of the biggest challenges in Scrum?
• Teams not self-managing
• Scrum Master managing not leading
Agile Process
Glossary
FAQ
Story points are estimates of effort as influenced by the amount
of work, complexity, risk and uncertainty
• Most popular way of estimation in Agile
• Relative sizing technique
• Entire team irrespective of specialty has to provide a single
estimate and not sum of individual estimates
• Usually scored on a scale of 1 to 10 (in order of difficulty)
Estimation - Story Point (SP)
Technique for Normalizing Story sizing:
• Find a small story and assign it one Story Point
• Estimate every other story relative to this story
• Points to consider while doing relative sizing:
Complexity, Knowledge and experience in the domain,
technology, Uncertainly, Volume, Repetition and Risk