Agile L1 Fundamentals

Day 1 Video 1

Introduction to Agile L1 Fundamentals

VUCA

Volatile

Uncertain

Complex

Ambiguous

Unlearning – important in Program Management

Traditional Methodologies

Waterfall Method

Spiral Method

Iterative Development

V-Model

- All take feedback only at the end

Traditional way of working

• First, define all the requirements

• Next, do all the design

• Implement everything

• Finally, verify it all

What happens if they fall behind schedule or need to make a change?

Thought?

A Shift to Agile Mindset

Agility
Being agile than doing agile.

Origin

Defined on February 11-13, 2001, at Snowbird ski resort in the Wasatch mountains of Utah by seventeen
people "The Agile Alliance," this group of independent thinkers about software development, and
sometimes competitors to each other, agreed on the Manifesto for Agile Software.

Agile Manifesto

Individuals and interactions over process and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

A minimum viable product, or MVP, is a product with enough features to attract early-adopter
customers and validate a product idea early in the product development cycle.
12 Agile Principles
1. Satisfy the Customer
Our highest priority is to satisfy the customer through early and continuous delivery of valuable
software.
2. Welcome Change
Welcome changing requirements even late in development. Agile processes harness change for
the customer's competitive advantage.
3. Deliver Frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
4. Work Together
Business people and developers must work together daily throughout the project.
5. Trust $ Support
Build projects around motivated individuals. Give them the environment and support they need
and trust them to get the job done.

6. Face-to-face Conversation
The most efficient effective method of conveying information to and within a development
team is face-to—face conversation.

7. Working Software
Working software is the primary measure of progress.

8. Sustainable Development
Agile processes promote sustainable development. The sponsors, developers, and users should
be able to maintain a constant pace indefinitely.

9. Continuous Attention
Continuous attention to technical excellence and good design enhances agility.

10. Maintain Simplicity

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

11. Self-organizing Teams

The best architectures, requirements, and designs emerges from self-organizing teams.

12. Reflect & Adjust

At intervals, the team reflects on how to become more effective, then tunes and adjusts its
behavior accordingly.

3Ps
People
Process
Product
Day 1 Video 2

Basics of Agile

What is Agile?
Agile is a time boxed, iterative approach to software delivery that builds working software
incrementally from the start of the project, instead of trying to deliver it all at once near the end.
It works by breaking the projects down into little bits of user functionality called user stories, prioritizing
them, and then continuously delivering them in short 2-week cycles called iterations.

At a High Level Agile is Philosophy and Framework

Designed to be iterative
Emphasizes collaboration between cross-functional teams
Requirements and solutions evolve throughout the project
Embraces change
Frequent demonstrations of functionality
Feedback is incorporated into future Sprints
Transparency drives trust and collaboration
Team reviews objective metrics for continuous improvement

Agile Umbrella ☂

Lightweight Approaches Fuller Approaches (beyond 1 team)

Scrum Scrum-of-Scrums
Lean software development Scrum at Scale (Scrum@Scale)
Kanban (process + method) Large-scale Scrum (Less)
Extreme Programming (XP) Scaled Agile Framework (SAFe)
Continuous Integration (Cl) Disciplined Agile Delivery (DAD)
Continuous Delivery (CD) Dynamic Systems Development Method (DSDM)
Feature Driven development (FDD) Agile Project Management (AgilePMl)
Test Driven Development (TDD) Agile Unified Process (AUP)
Crystal Clear Open Unified Process (OpenUP)

Advantage of Agile
Speed to Market
Risk Management
Quality
Right Product
Flexibility
Cost Control
Transparency
What Agile is not
• A silver bullet — benefits take dedication and efforts to achieve
• An undisciplined framework
• Not a lack of documentation or planning
• Not an excuse for missing dates
• Not an opportunity to blame others
• Not "unpredictable"
• Not 'change every day' — while embracing change, Agile does not allow change during sprints
Day 1 Video 2

Basics of Scrum

Fast Facts: Scrum is a Rugby Term

as in Rugby, the ball gets passed within the team as it moves as unit field

Takeuchi-Nonaka — The New New Product Development Game (1986)

Scrum

• Scrum is an Agile software development process to manage work

• Scrum teams adapt to rapidly changing requirements and priorities

• Scrum is an iterative, incremental framework for developing a product or managing work

• Scrum allows a potentially shippable functionality every iteration (or sprint)

• Scrum challenges users to on improvement

• Facilitate and empower vs. command and control

• Sprints provide stability to address the ever-changing needs that occur in every project

I Scrum Therefore I am Agile

5 Scrum Values
Courage:
Team members know they have the to work through conflict and challenges together,
so that they can do the right thing.
Commitment:
Team members individually commit to achieving their team goals, each and every sprint
Focus:
Team members Focus exclusively on their team goals and the Sprint backlog; there should be no work
done other than through their backlog
Respect.
Team members respect each other to be technically capable and to work with good intent.
Openness:
Team members and their stakeholders agree to be transparent about their work and any challenges that
they face
Scrum Process
Day 2 Video 1

Introduction to Scrum Roles

I. PRODUCT OWNER

Product Owner Is Responsible For

Gathering requirements from business owners or stake holders or some time from his/ her own

expectations

Break large requirements into small functionalities in the form of user stories. Subsequently these
functionalities are added to a place which is called Product Backlog.

Prioritizing the list of user stories in Product backlog

Make the development team understand the requirement and expectation of each user story in priority

Participate in major scrum ceremonies

Product Owner Has Authority to

1. Accept or reject the story completion

Product Owner has the authority to accept or reject the story completion, keeping DOD as rule

book. He/ She continuously work together with the team during each sprint, and provide feedbacks

by accepting or rejecting user stories when development team mark it as developed and tested.

2. Terminate any active sprint

If he/ she realize the committed user stories will not add any value increment to the specific sprint goal.

But a Product Owner

Should not act as Manager or external team

Is not the person for whom the Scrum Team develops the Product

Does not manage or deal with the team

II. SCRUM MASTER

The role of a Scrum Master is to protect the Agile Processes, maintain the discipline by ensuring the
team follows the best practices of agile and maximize the value increment.

Scrum Master Is Responsible For

Promoting and supporting scrum
Helping everyone to understand Scrum Theory, Practices, Rules and Value
Maximizing the value outcome
Serving to all other roles and cross-functional team as well

Establishing the Scrum Framework

Resolving Impediments
Protecting the team from outside interruptions and distractions
Enabling Transparency, and Adaptability
Establishing an environment of Agile development
Representing a holistic approach

But a Scrum Master

Is NOT a Manager and does not have authority to hire or fire
CANNOT take a decision of skill allocation or task allocation
DOESN’T solve the problem instead he facilitates problem solving
DOESN’T participate in estimation. However, SM facilitates the estimation process
 III. DEVELOPMENT TEAM

Development Team is a group of skilled resources, capable to analyze the requirements, make design
and develop it. This team is also capable of testing the developed code and mark it ready for review.

The Scrum Team – Summary

Role Description Performed By

Development Team 3 to 9 people who work together Composed of people with the required
jointly to deliver what the Product skills: Business Analyst, Tester
Owner requests
Supplemented by: Business SMEs,
DBA, Product Support, etc.

Product Owner Manages vision and ROI; defines and The person responsible must be able
prioritizes the features. Responsible to set the product vision and make
for the Backlog and ROI. business decisions about the product

Scrum Master Facilitates the Scrum Team, removes Could be anyone (Not an authority
promotes environment role). Person must be able to facilitate
the without getting bogged down in
work
Day 2 Video 2

Introduction to Scrum Ceremonies – Backlog Refinement

Sprint Ceremonies
Sprint Planning Meeting
Daily Stand-Up
Sprint Review Meeting
Sprint Retrospective Meeting

Backlog Refinement: Guideline

Why a team should not schedule Refinement on or just before Sprint Planning
• Few stories may not be ready as the definition of ready
• Few stories need more information to make it ready
• The Product Owner needs some time to clarify some of the doubts or clarification raised by Developer/
Tester
• Identified dependencies needs cross functional team's buy in team's buy-in for the current sprint. The
cross functional team may not have available bandwidth at the end moment
• Inefficient use of by lowering the velocity by less number of stories then the team is
capable of
• Leaving a chance of scope creep, by introducing new stories in sprint duration to compensate for the
available
capacity
• Introduce a practice of unwanted technical spikes that produce no value to business
Role-wise responsibilities in Backlog Refinement

Ceremonies Product Owner Scrum Master Development Team

Backlog Write User Stories, to Schedule Refinement Go through the raw story
Refinement meet DOR Meetings for upcoming stories to be
(Before) refined
Prioritize User Story Make sure the team is
aware of stories in priority Make doubts and
to be groomed questions ready to be
clarified
Backlog Explain user story one by Facilitate the Refinement Understand the
Refinement one as per the priority. requirement of the user
(During) Marked the stories status stories
Clarify all doubts and as groomed/ ready
questions from Identify the dependencies,
Development Team Facilitate Planning Poker - risk, complexity and
if estimating amount of work

Ensure development team Participate on estimating

fully understand the story points
requirements

Backlog Update the stories if any Circulate the Refinement May work on a tech spike
Refinement identified as not meeting outcome to all if created during grooming
(After) DOR
Calculate backlog health
Resolve open doubts if any and circulate resolve
identified during dependencies, risk if any
grooming. identified during
Refinement

Backlog prioritization using MoSCoW

I. Once there is a clear set of requirements, it is important to rank them. This ranking helps everyone
(customer, project manager, designer, developers) understand the most important requirements, in
what order to develop them, and what not to deliver if there is pressure on resources.
2. MoSCoW is a prioritization technique for helping to understand and manage priorities. It
helps us decide which requirements to complete first, which must come later and which to exclude.

M - Must have this requirement to meet the business needs

S - Should have this requirement, if possible, but project success does not rely on it

C - Could have this requirement if it does not affect anything else on the project

W - Would like to have this requirement later, but delivery won't be this time around
Outcome of Backlog Grooming

Mature and small User Story and elaborate Acceptance criteria

Healthy Prioritized Backlog

Defined Dependencies and Risks

Effective Sprint Planning

Increased Estimation Accuracy

Increased Efficiency
Day 2 Video 3

Introduction to Sprint Planning & Artifacts at Start of Sprint

DOR: Definition of Ready

For a Story
• User story is defined and understood
• Acceptance Criteria defined and understood
• Story can be completed in a Sprint
• Customer approval available for customer CRs/ customizations
• High Level Design available
• Dependent stories across silos are identified (linked in Jira) and groomed if possible
• Dependencies on the documentation such as updates to user manual, installation guide etc. are
identified and stories for documentation created (even if not groomed)

For Sprint
• Capacity Planning completed for sprint
• Sprint Backlog Identified and committed from the groomed product backlog
• Story DOR should be complete for all the stories identified for the sprint
• Dependencies across other teams are identified and the dependent stories are committed to the same
sprint or are already done.
• All the development, testing (manual / automation), spikes, grooming tasks are created.

Pre-requisites for Sprint Planning Meeting

How does a Spring Planning Meeting work?

Sprint Goal
What is Sprint Goal
Sprint Goal is a target or objective for a sprint. Which can be achieved by implementing set of
functionalities (PBI, User Stories, Bug Fixing etc.). The development team and Product Owner negotiate
and collaboratively set up a goal for a specific sprint or iteration. The goals are better to be measurable.
The selection of the Sprint backlog item from Product Backlog depends upon the goal. Sprint goal should
be short, 2 to 3 sentences.
Benefits
The business sponsor or stakeholders, prefer to get a vision from a birds eye view, rather than details
story level information. The sprint goal is always better to highlight what the team is doing. And, at top
level, if they are managing multiple teams, 2-to-3-line summary from each team is a useful information
The team commit to a goal and associated PBls, that helps the team to execute the sprint with a specific
vision.
Importance
During sprint review Product Owner, or stakeholders, verify the product increment by comparing the
goal
and how much is achieved. That defines the success of the sprint.
Example
• Implement the login screen functionality
•Implement the functionality to enable credit card payment on shopping cart
Role wise responsibilities in Sprint Planning Meeting

Ceremonies Product Owner Scrum Master Development Team

Sprint Identify the Sprint goal Have the capacity ready Have the individual
Planning Prioritize the stories and Request the team to be capacity updated (Leaves)
(Before organize the stories in aware of the stories in
Meeting) order, in product backlog order of priority Get an idea of the
upcoming stories
Top stories in backlog will
be picked first, keeping
the upcoming sprint goal
in mind

Make sure all the stories

in priority are groomed
and meeting the DOR
/DOD
Sprint Create and provide the Validate potential PBIs are Understand the story,
Planning sprint goal ready refine it (if not refined
(During earlier), Estimate in story
Meeting) Clarify the doubts (if any) Mark the User Story as point (if not estimated
of stories in discussion committed for sprint (if earlier)
team mutually agreed to
Navigate the stories in take that story) Create tasks on individual
priority one by one to Update the available level
check if the team can capacity. team member's
commit, keeping the allocation, overloading Assign the tasks to
sprint goal in mind etc. individuals

Make sure the stories Estimate hours for the

committed have an owner task
and have estimated story
points. Have proper tasks Validate available
created. individual bandwidth

Stop to pick more stories,

when the capacity is full
or almost full
Sprint Verify the sprint goal is Broadcast sprint planning Create tasks (if not
Planning met from the stories summary to all interested estimated during sprint
(After committed by the scrum members planning)
Meeting) team
Plan with team members,
to make the strategy to
work on the committed
stories
Day 2 Video 4

Introduction to Scrum Ceremonies – Daily Standup – Scrum

What is the Daily Scrum Call (Stand-Up)

• Daily Scrum Call or Daily Standup Meeting is a team collaboration meeting which happens every day
strictly for 15 minutes max.
• This allows synchronization within team members about sprint development states, progress and
impediments.

Basic Rules of Daily Scrum Call

Owned by Development Team and not by Scrum
This is not a Status Update Meeting
This meeting should not exceed 15 Minutes
This meeting should be conducted every day
Usually beginning of the day
Same time and Same Place
Development Team attendee is must for everyday (Scrum Master & Product Owner are Optional)
Please standup (Any reason why??)
What have you done yesterday?
What are you planning to work on today?
Are there any impediments?
Daily Scrum Call — Good Practices
Follow Rules
Mention your Name
Speak Loud
WFH? Join Digitally
Task Remaining Hour
Burn Down Chart
Park Long Discussion Items
Planned Leave
Distributed Team
DSC Duration
Keep Notes in Advance
Mention Impediments
No Cell Phone and other distractions

Daily Scrum Call —Avoid

External Interference
Avoid terms as status or updates
Technical Discussion
Requirement Clarification
Side Discussion
Change Meeting Time
Loosing Focus, Distracted
Role wise responsibilities in Daily Scrum Meeting

Ceremonies Product Owner Scrum Master Development Team

Daily Scrum Ensure, team have Update other team
(Before) updated the remaining members, if they are
hours in the scrum board unable to attend

schedule the Daily Scrum In case of OOO, update

Meeting their peer about their
story updates, risks,
impediments etc.

Update remaining hours

against each task they are
working on
Daily Scrum Participate, respond to Block outsider Talk about what they have
(During) any quick questions (No intervention on the last 24 hours, and
Longish Discussions), Re- what they are planning to
Prioritize Stories in scope Introduce new team work on next 24 hours.
of current sprint, if not members (if any) to all
started and required to Talk about impediments
change priority for various Facilitate, make sure the (if any) against any
reasons. team is talking about the
stories in scope and Synchronize between
making it short team and make a strategy
for the day
Refer bum down to check
the progress and identify
risks

Verify individual available

hours remaining Vs. Days
remaining in Sprint

Identify or provide
resolution, update on any

Stops lengthy discussion,

mark it for post Daily
Scrum Meeting discussion
item

Ensure the team is

following all Dos and
Don'ts for Daily Scrum
Meeting
Daily Scrum Ensure the team talks Complete the time taking
(After) about the side bar items discussion, marked as
(if any identified for post sidebar, related to scope
Daily Scrum Meeting), of the current sprint
then and there or offline

Action on impediments (if

any)
Day 3 Video 1
Introduction to Sprint Review Meeting, Sprint Retrospective

What is a Sprint Review Meeting (Show &Tell)

Sprint Review Meeting is an Informal Meeting to demonstrate the stories/ bug fixes/technical spikes etc.
they have worked throughout the current sprint (or just finished sprint).
• The team don't need to present any power point presentation or go through slides.
• Stakeholders explains visions and expectations from the team as future sprint deliverables.
• Scrum Master acts as a local coach for the meeting and makes sure that the meeting happens and
everyone follows the process properly

To Get all the functionalities demonstrated to stakeholders

To Identify new backlog items (if any)
To Re-prioritize Product Backlog Items (if required)
To Cover all aspect to close and conclude the sprint and get ready for next Sprint planning

NOT Demonstration to PO
NOT Story Acceptance Meeting

Sprint Review Meeting-Demonstration

Duration of Sprint Review Meeting
Typically, the time taken to complete this meeting is 1 hour per week of the Sprint duration. What that
means is, if a Sprint is 1-week long, the team can compete the meeting in 1 hour, where 2 week Sprint
takes max 2 hours and 3-week Sprint takes max 3 hours.

Time can vary depending on the below activities

• Welcoming time
• Introduction time
• Demonstration time
• New Backlog Item creation time
• Stakeholders vision discussion and future goal
• Discussion time
• New team needs coaching
• Customization or personalization
Role wise responsibilities in Sprint Planning Meeting

Ceremonies Product Owner Scrum Master Development Team

Sprint Review Last moment accept or May initiate meeting and Complete the stories and
(Before) reject stories of current invite the required make it ready to
sprint, i.e., during sprint members demonstrate, or review
execution is the best time
to accept or reject stories, However, Product Owner
as PO is part of the Scrum is the best person to send
team invites to stakeholders
and business sponsors
Identify stories ready for
demo

Send details scope of

demo

Invite stakeholders for

demo

Sprint Review Introduce team and Facilitate the review and Demonstrate the stories
(During) stakeholders demo completed, keeping
acceptance criteria in
Highlight scope of demo mind.

Demonstrate the new

functional increments

Discuss future sprint

scope

Identify scope of re-

prioritization

Identify new user story to

be created

Sprint Review Do re-prioritization Close the sprint

(After)
Create new user stories if Move the remaining
any stories to backlog

Prepare and circulate

sprint closure report, with
necessary metrics and
trends
Outcome of Sprint Review Meeting
Increment Inspection and Adaptive Backlog
Transparent Business Vision
New Backlog Items
Improve Collaboration
Up to date Prioritized Backlog
Team Motivation by Appreciation

DOD: Definition of Done

DOD For a Story

• Unit testing completed by the developer and evidences attached against the story
• Code review should be completed by peer/tech leads
• Test Cases should be attached to the user stories
• Test Results should be Captured
• Any bug identified should be linked with the story
• No bugs open against the story (exception by PO)
• Story should be validated by product owner and if the functionality is ready for release, story is
marked as Done

DOD For a Sprint

• Stories have met DOD
• Sprint level regression test completed
• Sprint Demo/ Show-n-tell done
• Sprint retrospective done
• Sprint marked "Closed" in Jira

What is Sprint Retrospective Meeting?

Participants in Sprint Retrospective Meeting

How Sprint Retrospective Meeting works

Collecting Retrospective Ideas

Adding Retrospective ideas to board
Retrospective Board Structure
Grouping of Retrospective ideas
Voting of Retrospective Board
Prepare Action items
Duration of the Sprint Retrospective Meeting

This meeting does not have a strict time boundary. You need to optimize the usage of the time, focus on
the primary agenda of the meeting and to inspect and adapt.
• Gather opinion of good and bad practices from the participants
• Rearranging, voting, group brainstorming on the retrospective points
• Prepare action items to improve your practice
• Optionally you can play some agile games, quiz etc. to build team moral and bonding

Time can varies depending on the below activities

• Team size
• Agile maturity
• Amount of controversy
• Conflict of action items
• Team building activities like quiz and games
• Participation of external team member

Average Time
Mature Team - 1 Hour
New Team - 2 Hours
Role wise responsibilities in Sprint Retrospective meeting

Ceremonies Product Owner Scrum Master Development Team

Retrospective Add or update Add or update Add or update
(Before) retrospective points, on retrospective points, on retrospective points, on

• What went well • What went well • What went well

• What did not go • What did not go • What did not go
well well well
• Improvement • Improvement • Improvement
areas areas areas
• Suggestions • Suggestions • Suggestions
• What the team • What the team • What the team
should stop doing should stop doing should stop doing
• What the team • What the team • What the team
will start doing will start doing will start doing
• What they will • What they will • What they will
continue doing continue doing continue doing
Retrospective Discuss Iast sprint Discuss Iast sprint Discuss Iast sprint
(During) retrospective items, and retrospective items, and retrospective items, and
open action items open action items open action items

Add or update Add or update Add or update

retrospective points, on retrospective points, on retrospective points, on
what went well, what did what went well, what did what went well, what did
not go well, improvement not go well, improvement not go well, improvement
area, suggestions, what area, suggestions, what area, suggestions, what
they should stop doing, they should stop doing, they should stop doing,
what they will start doing what they will start doing what they will start doing
and what they will and what they will and what they will
continue doing continue doing continue doing

Mutually identify the Facilitate the Mutually identify the

action items and retrospective action items and
assignments assignments
Mutually identify the
action items and
assignments
Retrospective Participate in resolving Prepare a retrospective Participate in resolving
(After) retrospective action items summary and circulate to retrospective action items
(if involved) the team and interested (if required)
parties
Circulate Retrospective
Ideas with Action Item Prepare an action tracker
and continue work on it,
Prepare a status tracker of in a frequency to get all
the action items, with the action item resolved
 progress status, initiated
date, primary owners etc.

Outcome of Sprint Retrospective Meeting

Action items
Inspect & Adapt
Improve Team Collaboration
Reduce gaps between Developer & Customer
Fun Activities Improve Team Bonding & Motivation
Day 3 Video 2
Introduction to User Story & Artifacts at the End of the Sprint

Burndown chart
The visual representation of the completed story points vs the pending story points against the original
plan

What is a User Story?

User Stories are most widely used Agile techniques to capture product requirements or functionality in
Agile software development, the execution level requirement or functionality is termed as user story. A
requirement (detail contents) in the user story needs to be sufficient enough so that:
Developer – can start and finish the development
Tester – can test the developed code to check if it is meeting the required functionality
Product Owner – can verify the desired functionality to accept the story completion
Development Team – can identify dependencies, risk, complexity, amount of work
Why User Story
User stories are written in business terms and not technical jargon which make them comprehensible by
both customers and developers.

User stories provide the right size for planning. Methods like release or sprint burndown and Kanban
boards assist the team to track progress.

Stories include acceptance criteria which helps in ensuring adequate test coverage and reduced rework.

Acceptance criteria ensures the expectations are clear to the developer even before they start coding.

Focus on value makes it easy to prioritize and re-order the product backlog.

Agile development has time-boxed iterations/ sprints and in case of a small portion of the scope
pending, the sprint is not held up and the team is able to deliver completed stories which deliver value
meaningful to business.

3C
Card
Conversation/Composition
Confirmation

Structure of User Story

A good user story five major segments to describe the requirements and its resting scenarios:
• Role
• Goal
• Benefit
• Description
• Acceptance Criteria

A typical template of a user story is like:

As a I want so that <Benefit/ Expected Outcome>.

<Acceptance criteria>

The Acceptance criteria is very crucial for a user story to use in unit testing, QA and story acceptance by
product owner or stake holders.
Characteristics of User Story (INVEST)
Independent - The story should be self-contained, in a way so that there are no inherent dependencies
on another story

Negotiable - User stories are not explicit contracts, and should leave space for discussion

Valuable - User stories must deliver values to the stakeholders or business

Estimable - You must be able to estimate the user story, once it is ready and groomed

Small - User story should not be so big that it becomes impossible to plan, task out, prioritize with
certainty

Testable - The user story and its related description must provide the necessary information to make
test-driven development possible

Characteristics of Acceptance Criteria (SMART)

Specific – Target a specific area of improvement or increment

Measurable – Quantify, or at least a possible indicator of progress

Achievable – Make it realistic that can be achieved

Relevant – Expectation should be related to the requirement, or the description of the story

Time Bound – Specific when the result can be achieved. Should have a specific duration or event
Who Can Write or Update User Story?

When User Stories Can be Written or Updated?

Creation - any time
Modification - any time till groomed/ - if changed after groomed - re-groom
Should Not Modify - after committed for a sprint

Hierarchy of User Stories

User Story Associations
Day 3 Video 3
Introduction to Scrum Key Areas – User Story Estimations

How Agile Estimation Using Story Point is Different

What are Story Points?

Agile estimation for user stories is an art of categorizing stories in different relative sizes, based on the
following 4 factors. These sizes are the Story Points
How Agile Estimation Using Story Point is Different

Traditional Estimation Story Point Estimation

Estimate is an inexact science and so estimation Estimates to identify value in agile and when
in time at the start of the project tend to either carried our frequently taking into account
overrun or under run learnings from previous sprint has a lower chance
of deviations
Estimate to get the timeline to compete the Estimate to plan how much (Values, Complexity
entire project/ product etc.), we can deliver in a single sprint or iteration
duration (typically 2 weeks)
We estimate development, testing and other Estimate the size of a story keeping in mind, its
effort separately for any functionality total effort (development, testing etc.) with its
risk’s dependencies and other factors
We estimate absolute values in hours or days We estimate relative sizing.
Estimate at the start of the project/ program Estimate between the development for upcoming
stories of future iteration, by applying lessons
learned from past sprints
Panels of technical experts, architects and other The agile team, mainly developers and testers do
members involved to estimate the estimation collaboratively, with presence of
Product Owner or Business Analyst & Scrum
Master

Story Point in Fibonacci Series

To estimate the size or the story point, we map a number value to it. It's done no matter what the
values are, what is important is the relative difference.

Three stories having story point 1, 2, and 3 is equivalent to having the story points as 10, 20, 30.
However the industry standard and to keep the practice uniform within the team, organization, or even
in the agile
world we use the points in Fibonacci Series, i.e., 1, 2, 3, 5, 8. Fibonacci series numbers have relative
difference with each other to give a Virtual Difference on your estimation.

Where story point 1 means very easy development with no risk, complexity, dependencies whereas
story point 13 means significant amount of complexity, possibilities of risk or dependencies Any story
appears to be more than 13 points we strongly recommend breaking the story in small stories.
Relative Sizing
As mentioned earlier, we do a relative sizing to bucket the user story with story point. To understand
why relative sizing is easy, refer the picture

From this picture, it’s very hard to measure the exact difference between the amount of water each
container can contain.

But it’s very easy to measure which container can contain more water and which container can contain
less. That's relative difference in size, that is what we do to measure story points.
Story Point Vs. T-Shirt Sizing

During estimation we need to think about $11 its aspects, i.e., Complexity, Risk, Dependency, Amount of
Work in development and testing etc.

Then we take a judgement of its overall size to assign a story point. It may sound complicated in the
beginning, but once you will start doing it, you will find it’s a fun and exciting exercise to do an
estimation.

To correlate your imagination to assign a story point to a user story. Categorize the size bucket as T-Shirt
size and map a story point from the Fibonacci series with that.

Uncertainty of Higher Story Point

We always try to break the story into smaller story for better estimation and visibility of its risk,
dependencies and technical aspects.

But we need to keep in mind each story has to be potentially shippable. We should not break a story on
the basis of its task like development in one story and testing in another story.

Breaking a story means splitting of an expected functionality by two independent smaller functionalities.

Higher the points means an increase in the uncertainty of its completion in time, because it has bigger
risk dependencies, and other unknown facts.
Story Point Estimation Technique

Estimating Stories with Planning Poker

Capacity Planning Steps

Step 1: Calculate - Sprint Duration
Step 2: List Down Team Members (Except SM and PO)
Step 3: Calculate Team Members Allocation
Step 4: Calculate Standard Working Hours / Day
Step 5: Consider the Following Factors (and additional ones, if any)
• Team Holiday
• Individual Planned Holiday
• Individual Partial day off
Step 6: Calculate Ceremony Time and Other Work

When Capacity Planning can be done

1. With Scrum Master's facilitation a Scrum Team can identify the capacity before the sprint planning.
The best time is just before the Sprint Planning for any specific Sprint. That gives the best visibility of
resources, their vacation plan and ceremony time.
2. If the teams are using any ALM tool, individual team can update their available time, Scrum Master
can help the team understand how to calculate their individual capacity.
3. Before hitting the sprint Planning, the Scrum Master can conduct a quick 30-minute meeting with the
team and get the capacity calculated and update accordingly.
4. A suggested best practice is to do this a day or two before the Sprint Planning on the
provided xls.
Benefits of Capacity Planning
Better Sprint Planning
Improve Commitment Reliability
Control Scope Creep
Better Allocation of Tasks
Day 4 Video 1
Introduction to Metrics

Agile Metrics (Scrum)

Capacity Utilization
Number of story points committed versus the available capacity (in days)

Team/Overall Productivity
Effort taken to deliver a story point
QC Defect density
Total number of QC defects detected during sprint for every story point completed (Sprint wise and
Cumulative)

Customer Defect density

Total number of customer defects detected for every story point completed

Commitment Reliability
Total number of story points committed vs. completed
Scope Change
Items added from the backlog or removed from the sprint scope during the sprint

Backlog Health
Total Story Points available in the Product Backlog compared with Average Velocity
Day 4 Video 2
Introduction to Kanban

What is Kanban?
Kanban is a method for managing the creation of products with an emphasis on continual delivery while
not overburdening the development team. Like Scrum, Kanban is a process designed to help teams
work together mere effectively.

This framework is highly productive and effective to run:

Ad-hoc requests
Unplanned work
Production support

It’s a method to visualize the flow of work, in order to balance demand with available capacity and spot
bottlenecks

Understanding Kanban Board: Multiple WIP Lanes

Kanban Background
Improved Management Through Visual Communication
Japanese Meaning = Visual Sign or Card (Invented by TOYOTA in 1940)
• Demand Based Supply
• Reduce Waste
• Maximize Value

Kanban Principles
Kanban promotes continuous collaboration and encourages active, ongoing learning and
improving by defining the best possible team workflow
Enhance Flow - When something is finished, the next highest thing from the backlog is pulled into play
WIP - Limit the amount of work in progress
Visualize Workflow - Visualize what you do today

Kanban Metrics

Response Time
The Response Time is the amount of time between the requested, and the team has started working on
it.

Cycle Time
The Cycle Time is the amount of time that the team spent actually working on the item (without the
time that the task spent waiting on the board). Therefore, the Cycle Time should start being measured,
when the item task enters the "Working" column, not earlier.

Resolution Time
The Resolution Time is the time from the moment when the request was made by a client and placed on
a board to when all work on this item is completed and the request was delivered to the client. So, it's
the total time the end user is waiting for an item to be delivered.

Throughput
Throughput is the amount of work items delivered in a given period of time, i.e., Week, Month, Quarter.
Understand Kanban – Scrum vs. Kanban

Scrum Kanban
Cadence & Delivery Regular time box in sprints Continuous Flow

Release Frequency At the end of each box or later Continuous Delivery

Roles Scrum Master, PO, Dev Team No defined role except the
development team. May be an
Agile Coach

Key Metric Velocity Cycle Time/Throughput

Scope Scope planned at sprint Work pulled into the system

planning, in a batch with bundle one by one
of work

Change Mechanism Scope planned at sprint Changes can be made any time
planning; no changes allowed
mid sprint

Applicability More appropriate in situations More appropriate in operational

where work can be prioritized in environments with a high
batches that can be left alone degree of variability in priority
Day 4 Video 3
Introduction to SAFe Agile

Why SAFe?
• Agile was a major step towards enabling a fundamental shift in work culture and behaviors, providing
a rapid feedback loop (fail fast, succeed faster) between the drivers of business requirements and
developers transforming them into solutions
• Agile was developed for small teams and, by itself, does not scale to the needs of the larger enterprise
(employees in an enterprise running 10, 20, or even hundreds of teams aligning with each other, the
customer, and the greater vision of the business)
• SAFe marries the iterative development practices of Agile with the mindset of Lean manufacturing and
the power of Devops. Lean thinking aims to use fewer resources and eliminate waste to maximize
customer value. SAFe combined with Lean enables organizations to scale the benefits of Lean and Agile
throughout every level of the organization, creating efficiencies, and linking strategy to execution.

Scaled Agile Framework

Essential SAFe

SAFe — Core values

Alignment - SAFe requires that companies put planning and reflection cadences in place at all levels of
the organization. With these in place, everyone understands the current state of the business, the goals,
and how everyone should move together to achieve those goals. By synchronizing and activities
regularly, all levels of the portfolio stay in alignment. Information flows both upward and downward in a
timely fashion, unlike traditional top-down, command and control

Transparency - SAFe trust-building behavior, including planning work in smaller batch sizes so
problems can be surfaced sooner, providing real-time visibility into backlog progress across levels, and
inspect and adapt rituals.

Built-in quality - In the SAFe framework, agility should never come at the cost of quality. SAFe requires
teams at all levels to define what "done" means for each task or project and to bake quality
development practices into every working agreement. According to SAFe, there are five key dimensions
of built-in quality: flow, architecture and design quality, code quality, system quality, and release quality.

Program execution - execution is the heart of SAFe and powers everything else in the framework. Teams
and must be able to deliver quality, working software and business value on a regular basis
SAFe Lean Agile Principles

1. Take an economic view

2. Apply systems thinking
3. Assume variability, preserve options
4. Build incrementally with fast, integrated learning cycles
5. Base milestones on objective evaluation of working systems
6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
7. Apply cadence, synchronize with cross-domain planning
8. Unlock the intrinsic motivation of knowledge workers
9. Decentralize decision-making
10. Organize around value