- Individual & Interaction Over Process & Tool
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- 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.
- Kent Beck
- Mike Beedle
- Arie van Bennekum
- Alistair Cockburn
- Ward Cunningham
- Martin Fowler
- James Grenning
- Jim Highsmith
- Andrew Hunt
- Ron Jeffries
- Jon Kern
- Brian Marick
- Robert C. Martin
- Steve Mellor
- Ken Schwaber
- Jeff Sutherland
- Dave Thomas
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress
- Agile processes promote sustainable development. Sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to tech. excellence and good design enhances agility
- Simplicity–the art of maximizing the amount of work not done–is essential
- The best architectures, requirements, and designs emerge from self-organizing teams
- 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”
- Inspect: Check & Revisit
- Adapt: Flexible to accept realities
- Transparency: Visibility
- Scrum master
- Product Owner
- Development Team
- Product Backlog
- Sprint Backlog
- Product Increment
- Sprint Planning
- Sprint Review
- Sprint Retrospective
- Daily Scrum
- 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
- Holds a small team
- Self-Organized team (Ceremonies)
- Self-managed team (PSI, Artifacts)
- Cross functional team
- Team decides how to develop
- Dedicated PO decides what to develop
- Team dedicated for the product
- Fixed sprint length
- Fixed scope for the sprint
- Small team 3-9 people
- Include servant leader-Scrum Master
- Follow Inspect – Adapt in every sprint
What SCRUM is NOT…
- A silver bullet
- A detailed & prescriptive one
- An estimation / prioritization model
- A methodology
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
- Product Owner
- Development Team
- Scrum Master
- Heart of Scrum
- Self- Organized
- Cross- Functional skills
- Who commits
- Size 3-9
- No Job titles
- No Sub Teams
- 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”
Different forms of PBI – Product Backlog Items
- User Stories / FRs
- NFR’s / POC
- 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
- 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.
SIZE + EFFORT + COMPLEXITY + TIME + DEPENDENCIES
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
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
- 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
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
Scope: A dynamic Scope rather than Fixed, A Experimental projects Requirement evolves over market demand.
Time: Timeline of the project should be realistic to Agile Approach.
Organizational Culture: Where customer is involved and appreciate feedback rather upfront planning with no feedback.
Criticality: When Project is running with a critical time frame. A tight time to Market
Changing & Unstable Environment Frequent Technology change platform.
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).
Collocation: Collocation encourages agile practices and helps team works faster with common vision and sharing knowledge.
High Risk, High Unstable: Agile adopted for any creative projects where there is possibility of high risk
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
Project Governance: Supportive Management Philosophy and should adhere to Agile philosophy. At least aware on philosophy.
Incremental delivery: Incremental & Iterative delivery model works better than big bang. Project should be able to breakdown into modules to deliver in Iterations.
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
- Discuss on technical aspect, Dev, QA & Testing
- Discuss on design / architecture
- Break stories into task
- Estimate tasks
- Team commit and pull the user story.
- Team continue pulling user story until capacity is full.
- Team define the sprint goal.
- Team continue tasks
- Attend daily stand up
- Maintain sprint backlog
- Update burndown chart
- Raise dependencies
- Collaborate to develop
- Empowered & Self Organized
- Remove obstacles
- Host ceremonies
- Support in info. radiator
- Work with PO
- Help updating release plan
- Focus on Process & People
- Demonstrate Servant Leadership
- 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?
- Avoid centralized decision
- No autocratic
- Avoid unrealistic estimation
- Team is not empowered
- Avoid imposed decision
- No command to team
- Team owns their tasks
- 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)