1. Individual & Interaction Over Process & Tool
  2. Working Software Over Comprehensive Documentation
  3. Customer Collaboration Over Contract Negotiation
  4. Responding to change Over Following a Plan

That is, while there is Value in the items on the Right, we value the items on the Left More.

  1. Kent Beck
  2. Mike Beedle
  3. ArievanBennekum
  4. Alistair Cockburn
  5. Ward Cunningham
  6. Martin Fowler
  7. JamesGrenning
  8. JimHighsmith
  9. Andrew Hunt
  10. Ron Jeffries
  11. Jon Kern
  12. BrianMarick
  13. Robert C. Martin
  14. Steve Mellor
  15. Ken Schwaber
  16. Jeff Sutherland
  17. Dave Thomas
  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. Sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to tech. 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

“ A simple frameworkwhich brings people together to address complex and adaptive problems while productively and creatively delivering products of the highest possiblevaluesin an incrementalway by providing aclear visibilityduring the progress and bringing improvements regularly

  1. Inspect: Check & Revisit
  2. Adapt: Flexible to accept realities
  3. Transparency: Visibility

Scrum Poster Agiletrick

3 Roles

  1. Scrum master
  2. Product Owner
  3. Development Team

3 Artifacts

  1. Product Backlog
  2. Sprint Backlog
  3. Product Increment

4 Ceremonies

  1. Sprint Planning
  2. Sprint Review
  3. Sprint Retrospective
  4. Daily Scrum

Scrum Is:

  • A simple, incremental, iterative framework
  • Multiple feedbacks
  • Simple to learn but difficult to implement
  • Surface out weaknesses in the team
  • Hard and Disruptive –Ken Schwaber, 2006

12 Notes on SCRUM

  1. Holds a small team
  2. Self-Organized team (Ceremonies)
  3. Self-managed team (PSI, Artifacts)
  4. Cross functional team
  5. Team decides how to develop
  6. Dedicated PO decides what to develop
  7. Team dedicated for the product
  8. Fixed sprint length
  9. Fixed scope for the sprint
  10. Small team 3-9 people
  11. Include servant leader-Scrum Master
  12. Follow Inspect – Adapt in every sprint

What SCRUM is NOT…

  • A silver bullet
  • A detailed & prescriptive one
  • An estimation / prioritization model
  • A methodology
  1. Commitment
  2. Courage
  3. Transparency
  4. Focus
  5. Respect

A fixed smallest possible time box just enough to deliver one or multiple smallest shippable business value increments

“Timebox is a short span of time. Time boxing is setting a fixed time limit to overall scrum ceremonies and letting other characteristics such as scope vary.”

  • Author of Product Backlog
  • Product Expert
  • Subject Matter Expert
  • Stakeholder Communication
  • Product Vision
  • Scope Management
  • Product Cost Management
  • Maintain the Product Backlog
  • Develop Product Vision
  • Maximize ROI, Market Analysis
  • Prepare & Maintain backlog
  • High Authority in backlog &priorities
  • Groom Product Backlog
  • Dedicated for the product
  • Review product increments.
  • Collaborate with stakeholders
  • Demonstrate to sponsor
  • Update release plan in respect with Team estimation
  • Scrum Knowledge
  • Coaching-Mentoringskill set
  • Servant Leader
  • Change Agent
  • Facilitate Scrum Meetings
  • Ensure process is followed
  • Supportteam.
  • RemovesObstacles.
  • Establish Scrum practices
  • Establish communication
  • Ensure team follow Scrum
  • Helps in managing scrum artifacts
  • Teams Scrum Coach
  • Keep team focused on vision
  • Keep PO focused on PB
  • Change Agent

Scrum Team:

  1. Product Owner
  2. Development Team
  3. Scrum Master

Development Team:

  • Heart of Scrum
  • Co-location
  • Self- Organized
  • Cross- Functional skills
  • Who commits
  • Focused
  • Size 3-9
  • No Job titles
  • No Sub Teams
  • Empowered
  • Demo work results to PO
  • Scale by adding team, not team members

List of activities or tasks required to be completed to produce a deployable product increment. This is defined and agreed by scrum team.


  • Solution meets acceptance criteria
  • Code is unit tested to have at least 85% coverage
  • Any new code introduced should have 80% unit test coverage.
  • Design and Code are reviewed
  • Acceptance and Regression tests are developed & reviewed
  • Impacted functionalities are identified and tested with no open defects.
  • All Tests executed and passed

In simple Examples:

Code Checked-in, Code automated test passed, Code quality met, Code integration passed, Releasable, Acceptance tested, Documentation standard, Coding Standard, Global concerns like security, performance etc.)

List of activities required to be completed to consider a product backlog item ready for move into sprint. This is defined and agreed by scrum team.

“A singlecontainer,Awish-list, whichholds all prioritized user requirements and get refined continuously to fulfil the product vision is called Product Backlog. Every single item list called as Product Backlog Item”

User requirements


Supporting needs



Different forms of PBI – Product Backlog Items

  • UserStories / FRs
  • Defects
  • NFR’s / POC
  • Risks
  • Technical Debt
  • ChangeRequest
  • BusinessNeed -VOC

Bill Wake’s:INVEST Model

I– Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Three Parts (3C’s Ron Jefferies)

  • Card: Brief Description / Stories are written on an index card, with estimates & notes
  • Conversation: Fleshing out details /Detailed are explored during conversation with PO
  • Confirmation: When story will be done / Based on acceptance tests written for a user story

As a <role>, I want <goal/desire> so that <benefit/ Impact>“

As a  < Who wants this piece of functionality >

I want< What the user wants >

So that< Why the user wants it >

  • Placeholder to capture user’s view.
  • Helps in delivering business value.
  • An agreementbetween businesspeople and developersto continue discuss and explore moreduringthe sprint planning.
  • Simple way to represent business requirements.
  • Helps team to focus on delivering smallest business value.
  • Engage PO
  • Conversation leads to:
  • Acceptance Criteria
  • Architectures
  • Algorithms / Rules
Theme: A set of related user stories that may be combined together and treated as a single entity for either estimating or release planning.
Epic: Large user stories which may span across multiple sprint, with lower priority. They are too big to implement in a single iteration and therefore they need to be broken down into smaller user stories at some point
SPIKE: Spiking is A risk reduction technique where team creates a POC and add that as a technical story in backlog. This is termed as a high risk and high unknown technical requirements. This is addressed through early sprints.

Estimating size with story points Story Points are a unit of measure for expressing the overall size of a user story, feature, or other piece of work The number of story points associated with a story represents the overall size of the story.


Who: By Development Team

When : During Sprint Plan meeting

How: Measuring by Story point ( Task )

What: Using planning poker game ( Expert Opinion )



  • Non Linear Scale – Fibonacci Series [1,2,3,5 and 8]
  • Non Linear Scale – Doubles / Exponential [1,2,4 and 8]

Planning Poker Game:

  • All team will participate
  • Create a common view
  • Estimate on overall work
  • Use relative estimation
  • Pull cards at same time
  • Discuss differences
  • Bring common agreement

Note: This game is widely used by Scrum Team but not a part of scrum.

Business Value Priority


Effort Required


Tech. Complexity


Inter Dependencies


Degree of Uncertainty


Cost of Development

Whyis it required?

  • To enable development team consider top priority stories into next sprints which are highly elaborated.
  • Bring a better clarity on user stories

Whenit should be done?

  • Every sprint once
  • When any new business need evolve

Whatshould be done?

  • Improve acceptance criteria
  • Prioritize
  • Split Story
  • Estimate / Re-estimate
Who facilitate this?Scrum Master
Who attend this?Development team, Scrum Master(Facilitator), PO (Mute)
Whenoccur?Everyday, Team decide best possible time.
Whatis discussed?What I did since last meeting? ( Whatchanges brought )

What I will dotoday? ( What is left to do )

What is my road block? ( Who need help & from whom )

Why is it requiredA short daily meeting, All team members inspect and adapt toward sprint goal and expose roadblocks


  • Ideal : 15 Minutes for 6-9 Team Members
  • Same time & Same place every day
  • No to “HOW” & Solving Problems
  • Mute spectators are allowed
  • Standing helps in attentive & short discussion
  • Risks are identified
  • Task pulling ( Who can take more tasks )

Velocity isthe pace of team’s progresspersprint.It is calculated by summing the number of story points assigned to each user storywhich theteamhas completedduring thesprint and accepted by PO.

Who facilitate this?Scrum Master
Who attend this?Developmentteam, Scrum Master( Facilitator), PO,Chickens
Whenoccur?Once, End day of every Sprint
Whatis discussed?1.DOD & DOR

2.Sprint Backlog

3.Acceptance Criteria for user stories.

Why is it requiredDemonstrate the DONE user stories ( scenarios completed, Working User Stories with test scenarios)  and secure the feedback

A regular inspection by theteam,todiscuss how they areworking and looksback on a past workto learnfrom their experience and apply this learning to futuresprints.

3 Points to cover during Retrosective

  • What works well?
  • What doesn’t work so well?
  • What do we need to start doing?

How can we determine Sprint Length?

  • Thelength of therelease
  • Theamount of uncertaintyin work
  • Theease of getting feedbackfrom business owner and end user
  • Howlong priorities can remain unchanged
  • Willingnessto go without feedback(Threshold)
  • Theoverhead of iterating
  • Afeeling of urgency is maintained
  1. Scope: Adynamic Scope rather thanFixed,A Experimental projects Requirement evolves over market demand.
  2. Time: Timelineof the project should be realistic to Agile Approach.
  3. Organizational Culture: Wherecustomer is involved and appreciate feedback rather  upfront planning with no feedback.
  4. Criticality: WhenProject is running with a critical time frame. A tight time to Market
  5. Changing &Unstable Environment Frequent Technology change platform.
  6. Team Size:Agile projects running with a small team similar to 3-9 with  capability of all  function like DEV, QA, BA, Tester and Business(PO).
  7. Collocation: Collocation encourages agile practices and helps team works faster with common vision and sharing knowledge.
  8. High Risk, High UnstableAgileadopted for anycreativeprojectswhere thereis possibility of high risk
  9. Self sufficient:Agile best suits when the team is crossfunctional,self organized mindset.Cleardedicated role defined as Product Owner, Scrum Master, development team
  10. Project Governance: Supportive ManagementPhilosophyand should adhere to Agile philosophy. At least aware on philosophy.
  11. Incremental delivery:Incremental & Iterative delivery model works better than bigbang. Projectshould be able to breakdown into modules to deliver in Iterations.
  12. Environment:A collaborative,Flexible & Adaptive Environments helps agile projects

Planning Meeting– I Activities

1.Product owner explain top priority user stories

2.Team clarifies the business need & acceptance Criteria

3.Team estimate the user story & evaluate the capacity

Planning Meeting– II Activities

  1. Discuss on technical aspect, Dev, QA & Testing
  2. Discuss on design / architecture
  3. Break stories into task
  4. Estimatetasks
  5. Team commit and pull the user story.
  6. Team continue pulling user story until capacity is full.
  7. Team define the sprint goal.

Development Team:

  • Team continue tasks
  • Attend daily stand up
  • Maintain sprint backlog
  • Update burndown chart
  • Raise dependencies
  • Collaborate to develop
  • Empowered & Self Organized

Scrum Master:

  • Remove obstacles
  • Host ceremonies
  • Support in info. radiator
  • Work with PO
  • Help updating release plan
  • Focus on Process & People
  • Demonstrate Servant Leadership

Product Owner

  • Maintain product backlog
  • Ready with demand flow
  • Update release plan
  • Support in business logic
  • Rewrite, prioritize stories
  • Focus on Business Need
  • Maximize Business Value
  • No direct role in Scrum Team
  • Moved to extended Shared team
  • No direct authority over scrum team
  • No appraisal inputs
  • Support in policies
  • Support in governance
  • Support in program management

Why PM Role is missing in Scrum?

  1. Avoid centralized decision
  2. No autocratic
  3. Avoid unrealistic estimation
  4. Team is not empowered
  5. Avoid imposed decision
  6. No command to team
  7. Team owns their tasks
  8. Team takes decision on how
Whocreate this?Development team
When created?During sprint development,(Exclude planning, review-retro day)
Who & whenupdates?Whena task, work is done, mostly daily basis
Whathappens?Track planned vs. actual progress, Mostlyremaining TO DO

Visualize project progress with committed

PrerequisitesPhysical board to track/ Online tool for generating graph/ Manual
Why is it requiredIdentify what areremaining to complete, health of the sprint

Sample Example (Image taken from Google)

A Quick Reference Guide Book

Want to know more?

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.


Start typing and press Enter to search