Course name - Agile Scrum Essentials

agile scrum methodology and how to apply them

how to work together
not one line of code

->agile and why it works

->agile requirements and estimation
->scrum
->agile planning
->lean software development
->flow well
->agile patterns
->anti patterns

4.Agile and why it works:-

-> comparing development processes

-> why the agile is and is not
-> contemporary agile methodologies

5.Comparing Development Processes

-> Winston Royce's waterfall model---1970 IEEE paper

----------------------------------

stage1:-requirement specification
stage2:-design
stage3:-construction
stage4:-testing and debugging
stage5:-installation
stage6:-maintenance

group of people make manifesto on agile sd

6.The Big Difference in

*plan driven software development

Planning-Analysis-Develop-Test Integrate-Validate-Deploy

*gile Software Devlopment:

analysis analysis analysis analysis

develop develop develop develop
test test test test-------deploy
intigrate intigrate intigrate intigrate
validate validate validate validate

->small release
->customer satisfaction
->start goal finish need
->very interactive

7.graphing agile vs plan driven:

-> high visibility in agile.
-> low visibility in plan driven.
-> ability of change is very high in agle.
-> ability of change is very low in paln driven
-> business value is high - generate more revenue
-> We can take risk at first (challenging part)

8.what agile is and is not:-

working with people

working with software

**what is?
->iterative
->adaptive
->value based
->easy to understand
->hard to implement

**What not?
-> just about writing code
-> undisciplined
-> unstructured
-> whatever you want it to be
-> a placebo for pesky developer

9.contemporary agile methodologies.

10.Xp (extreme programming)

-> earliest method

-> success in smaller tean not for large team
-> 12prectices
-the planning game
-small relese
-metaphor
-simple design
-testing
-refectoring
-pair programming
-continuous integration
-collective ownership
-on-site customer
-the 40 hour week
-coding standards

11.Scrum

->iterative
->in 1990
->not any specific technique
->beyond software development
->blends with XP
->simple

product backlog->sprint backlog->2-4 week sprint(24 h)->full app

12.lean software development

->eliminate waste
->amplify learning
->respect people
->build quality
->differ commitment
->deliver fast
->recognize and optimize fast

13.feature driven development:-

->1997
->more effectively than scrum

*activities
->develop overall model
->build feature list
->plan by feature
->design by feature
->build by feature

*milestone
->domain walkthrough
->design
->design inspection
->code
->code inspection
->promote to build

14.summary

ref->agile manifesto.org,Agilealliance.org

MODULE INTRO 2
-> effective requirements
-> user stories
-> estimating work
-> planning poker

2.1,effective requirements:-

What is requirements?
->a feature, behavior, or constraint to be added to a system
->a prelude to a conversation
->a req for someone to do work
->a request for software to change

What is not?
->a solution design
-> a decision about implementation
->typically illustrative of the final deliverable
->source of truth

independent
negotiable
valuable
estimable
sized appropriately
testable

2.2,User Stories:-
best way to communicate

-> as a (role) i want (feature) so that (benefit)

->
2.3,Estimating work:-

->to plan and proceed deliberately

->to get a feel for costs
->to calculate potential of ROI
->to understand the size of something
->to know if work even can be done
->to weigh options

*way of estimate software:-

-darts
-give it to manager
-ask the expert
-without bothering the developers

how to measure?
->line of codes
->buckets per day
->cycles per month
->mega jewels per nanoseconds
->coffees per day
->rotation per minute
->feature points
->kilowatts per hour
->hertz
->miles per hour

2.4,story points:-

very common way to estimate story point

based on size complexity not duration
unitless and numerically relative
different for each of team estimators
points are additive, unlike time
easy to use and understood

x project is how bigger than y 1x,2x,3x,4x?

Estimates are not promises

2.5, pocker planning.

->group deliver more accurate than individual

->political trading etc.
->instead of time we use word complex and bigger
very accurate
relative size
How Planning Poker Works:-
->Team Selection: The development team, product owner, and scrum master
participate.
->Story Explanation: The product owner explains a user story or task to be
estimated.
->Discussion: The team discusses the story, clarifying uncertainties.
->Card Selection: Each developer secretly selects a Planning Poker card (with a
number) representing their estimate. Common scales include:
->Fibonacci Series: 1, 2, 3, 5, 8, 13, 21, etc.
->Powers of Two: 1, 2, 4, 8, 16, etc.
->T-shirt Sizes: XS, S, M, L, XL (less common).
->Reveal Estimates: All participants reveal their selected cards simultaneously.
*Discussion of Differences:
If estimates vary significantly, team members discuss their reasoning.
Those with high or low estimates explain their perspective.
Re-estimation (if needed): The team repeats the process until they reach a
consensus

3.SCRUM:

->origins of scrum
->principals
->the scrum model
->roles
->artifacts
->ceremonies
->activities

3.1 Origins of scrum

->

3.2 Principals behind the methodology

->small working teams

->embracing changing requirements
->deliver finished work frequently
->small batches
->enable releasing product whenever required

*Characteristics of scrum

->activities are time boxed

->all metrics, reports and deadline are prominently displayed
->multi disciplinary and self organized teams
->no specific engineering practices prescribed
->sprints
->requirements are take from product backlog
->continuously test as it is created

3.3 the basic scrum framework

Roles: Product Owner, Scrum Master, Development Team.

Artifacts: Product Backlog, Sprint Backlog, Increment.
Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

Scrum promotes team collaboration, focus on value, and continuous improvement. It’s
designed to adapt to changing requirements and improve product quality through
iterative feedback.
3.4 who uses scrum and why

Scrum is used by a wide range of teams across different industries because it helps
them:

Adapt to change quickly and efficiently.

Collaborate more effectively, leveraging diverse skill sets.
Deliver high-quality products in iterative cycles, ensuring continuous value.
Improve processes and team performance through feedback loops.

3.5 roles in scrum

In Scrum, there are three main roles within a Scrum Team: Developers, Product
Owner, and Scrum Master. These roles work together to ensure that Scrum is
implemented effectively, and the team can deliver a valuable product increment at
the end of each sprint.

Developers: Create the product increment, ensuring it meets the Definition of Done
and adapts daily to the Sprint Goal.

Product Owner: Manages the Product Backlog, prioritizes items, and ensures the team
works on the most valuable tasks to meet the Product Goal.

Scrum Master: Ensures that Scrum is being followed, helps remove obstacles, and
supports the Scrum Team and Product Owner in achieving success.

Each role has specific responsibilities, but they all work together as part of the
Scrum Team to achieve the Product Goal and deliver high-quality, incremental
product value.

3.6 Scrum Artifacts:

Product Backlog: A list of everything that is required to build the product,

prioritized by the Product Owner. It evolves and is refined over time.

Sprint Backlog: A list of tasks and user stories selected from the Product Backlog
that the Development Team works on during a sprint to achieve the Sprint Goal.

Increment: The potentially shippable product that results from the sprint. It must
meet the Definition of Done and be a completed, working piece of the product.

These artifacts are transparent, visible, and regularly updated, ensuring the Scrum
Team and stakeholders can make informed decisions about progress and priorities.

product backlog
sprint backlog
sprint burndown chart
scrum team velocity

Product Backlog: A prioritized list of all work needed to develop the product,
owned and maintained by the Product Owner.

Sprint Backlog: A subset of the Product Backlog selected for the current sprint,
including the Sprint Goal and tasks for the team to work on during the sprint.

Sprint Burndown Chart: A chart that tracks the remaining work versus time during a
sprint, helping the team assess whether they are on track to meet their Sprint
Goal.

Scrum Team Velocity: A metric that measures the team's capacity by tracking the
amount of work completed in each sprint, allowing for better forecasting of future
work.

These artifacts and metrics are essential for tracking progress, improving
performance, and ensuring the team can meet their goals effectively and
consistently.

3.7 Scrum Event:-

3.8 Scrum Activities:-
*product backlog planning:-
->5=15% of teams time
->happens continually during sprint
->is facilitated by the product owner
->account for it when planning sprint
-------------------------------------
->sprint planning
->sprint: Daily scrums, product backlog planning
->sprint review
->sprint repository
----------------------
used to build the product backlog
centers around estimating product backlog items
often elicits overall system approach or architecture
must be facilitated well to avoid digression
goals don't change in the sprint

3.9 Scaling Scrum:-

->a meeting with scrum masters and organizational leaders

->used to coordinate the work of multiple scrum teams
->needs executive sponsorship ideally attendance
->may not need daily
->must have people in attendance who can make resource

Why Scale Scrum?

Manage large, complex projects
Improve communication & alignment
Ensure efficient collaboration

Challenges in Scaling:
Coordination & dependencies between teams
Communication gaps
Loss of agility due to added structure
Best Practices:
✔ Use a single Product Backlog
✔ Conduct Scrum of Scrums meetings
✔ Keep teams small & autonomous
✔ Automate testing & deployment

#Summary:-
backlog
backlog item
burndown
daily scrum
scrum team
sprint
sprint backlog
sprint review
task
velocity

summary of my experience
fewer defects
higher production development
quicker market response
sustainable pace and enjoyable workplace
make the right thing sooner

4.Traditional plans

->traditional plans
->agile planning
->planning a release
->techniques of iteration planning
->the daily plan

->the Winchester house

->perfect execution of a clear vision with no plan
->mars climate orbiter
destroyed because unit conversion error in software

->A good plan is

-clear
-reliable
-used
-available

traditional plans
plan activities not deliverable
rely on strict sequencing
time over runs are passed to next phase
are developed for systems instead of feature
assert that the end result is known

Why need plans?

plan constantly not just in starting
activity not an document
be constant
historical performance
change in plan does not mean change in time
don't control change encourage

levels of agile planning

product release plan

product backlog
interaction/sprint backlog
daily plan

#basic types of release planning

->data target planning
->feature target planning

we do both --- is not possible

rule 1
->an accurate release planning requires a prioritized
and estimated backlog

rule 2
-> an accurate release planning requires known velocity

#Product roadmap
->communicate the big picture
->determine and communicate when release are needed
->determine which functionality is sufficient for each release
->focus on business value derived for each release

#Poduct Release plan

->predicts to what extent we are poised
->provide tangible targets of functionality and dates backed by the reality of the
product
->used to make reality based decision

#Product backlog ownership

1 team many backlog
many teams on huge product

which view of the backlog is real?

->team view--close to reality
->division view
->theme view
->product view
->system view
->release view--close to reality

#iteration planning

->first day of new iteration

->time boxed
->everyone involved on the work is present
->the point is to plan the next iteration only
->the goal is to make a to do list for the upcoming iteration

#velocity based
->uses avg velocity over time or uses velocity of last iteration
->Most useful with long historical record
->unreliable in what will be accomplished
->assume conditions are constant across iterations

#commitment based planning

->team commits based on what they believe to be true right now
->likely to lead to realistic expectations
->uncovers feature impediments now
->forces team to be deliberate in their thinking

->discuss highest priority backlog

->decompose it into tasks
->whole team estimate each task in ideal time
->team answer can we commit to this?
->if yes see if we can add another backlog item
->if not remove this item but see if we can add another smaller one

#Ideal time:

->how long something would take if

->its all you worked on
->everything you need is available?

#The Daily Plan

*the daily(scrum, standup, panning session)
->sharing commitment

->communicate daily and plans to the team any observers

->identify impediments
->set directions and focus
->regularly relying the team builds a stronger team

#tips for staying effective

#information radiators

1.task Board
2.Aburnout chart
3.Historical view of team velocity
4.current build status
5.number of current outstanding defects
6.number of passing tests
7.current code coverage
8.relese plan