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. Arie van Bennekum
  4. Alistair Cockburn
  5. Ward Cunningham
  6. Martin Fowler
  7. James Grenning
  8. Jim Highsmith
  9. Andrew Hunt
  10. Ron Jeffries
  11. Jon Kern
  12. Brian Marick
  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 framework which brings people together to address complex and adaptive problems while productively and creatively delivering products of the highest possible values in an incremental way by providing a clear visibility during 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-Mentoring skill set
  • Servant Leader
  • Change Agent
  • Facilitate Scrum Meetings
  • Ensure process is followed
  • Support team.
  • Removes Obstacles.
  • 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 single container, A wish-list, which holds 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

  • User Stories / FRs
  • Defects
  • NFR’s / POC
  • Risks
  • Technical Debt
  • Change Request
  • Business Need -VOC

Bill Wake’s: INVEST Model

I – Independent

N – Negotiable

V – Valuable

E – Estimable

S – Small

T – Testable

Three Parts (3 C’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 agreement between business people and developers to continue discuss and explore more during the 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

Why is it required?

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

When it should be done?

  • Every sprint once
  • When any new business need evolve

What should 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)
When occur? Everyday, Team decide best possible time.
What is discussed? What I did since last meeting? ( What changes brought )

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

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

Why is it required A 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 is the pace of team’s progress per sprint. It is calculated by summing the number of story points assigned to each user story which the team has completed during the sprint and accepted by PO.

Who facilitate this? Scrum Master
Who attend this? Development team, Scrum Master( Facilitator), PO, Chickens
When occur? Once, End day of every Sprint
What is discussed? 1.DOD & DOR

2.Sprint Backlog

3.Acceptance Criteria for user stories.

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

A regular inspection by the team, to discuss how they are working and looks back on a past  work to learn from their experience and apply this learning to future sprints.

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?

  • The length of the release
  • The amount of uncertainty in work
  • The ease of getting feedback from business owner and end user
  • How long priorities can remain unchanged
  • Willingness to go without feedback (Threshold)
  • The overhead of iterating
  • A feeling of urgency is maintained
  1. Scope: A dynamic Scope rather than Fixed, A Experimental projects Requirement evolves over market demand.
  2. Time: Timeline of the project should be realistic to Agile Approach.
  3. Organizational Culture: Where customer is involved and appreciate feedback rather  upfront planning with no feedback.
  4. Criticality: When Project 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 UnstableAgile adopted for any creative projects where there is possibility of high risk
  9. Self sufficient: Agile best suits when the team is cross functional, self organized mind set. Clear dedicated role defined as Product Owner, Scrum Master, development team
  10. Project Governance: Supportive Management Philosophy and should adhere to Agile philosophy. At least aware on philosophy.
  11. Incremental delivery: Incremental & Iterative delivery model works better than big bang. Project should 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. Estimate tasks
  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
Who create this? Development team
When created? During sprint development, (Exclude planning, review-retro day)
Who & when updates? When a task, work is done, mostly daily basis
What happens? Track planned vs. actual progress, Mostly remaining TO DO

Visualize project progress with committed

Prerequisites Physical board to track / Online tool for generating graph/ Manual
Why is it required Identify what are remaining 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