Agile Software Development - Agile and Scrum Intro
-
Upload
kaushik-saha-sr-business-analyst-csm-csp-apo-icp -
Category
Documents
-
view
168 -
download
3
Transcript of Agile Software Development - Agile and Scrum Intro
1
Agile Software Development
Agile software development is a group of software development methods in which solutions evolve through collaboration between self-organizing, cross-functional teams.
It promotes adaptive planning, evolutionary development, frequent and early delivery, continuous improvement, and encourages rapid and flexible response to change with iterative and incremental approach.
2
Agile Manifesto
Individuals and Interactions
Processes and Tools
Working SoftwareComprehensive Documentation
Customer Collaboration Contract Negotiation
Responding to Change Following a Plan
Over
Over
Over
Over
3
Agile Principles• 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.
4
Agile Principles• 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. The
sponsors, developers, and users should be able to maintain a constant pace indefinitely.
• Continuous attention to technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done--is essential.
5
Agile Principles• 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 behaviour accordingly.
6
Why Agile
• Accelerate Time To Market• Early and Continuous Delivery• Frequent Customer Feedback• Greater Visibility into Project Progress• Early Defect Detection and Prevention• Risk Reduction and Quality Improvements• Improve Team Morale
7
Waterfall Vs Agile
8
Development in AgileAgileAgile uses interdisciplinary teams in iterative cycle, reduces waste and increases productivity 1-4 Weeks Sprint(s)
Agile Release Planning
Code
Analysis
Test
Design Code
Analysis
Test
Design
9
Various Agile Methods
10
What is Scrum• Scrum is a process framework structured to support complex product
development.
• Scrum consists of Scrum Teams and their associated roles, events, artifacts and rules.
• Scrum is performed by cross-functional teams over multiple overlapping phases (such as, analysis, design, code, test, etc.)
• NOT a software engineering practices, supportive to agile manifesto and principles.
• Scalable to distributed and large teams
11
Why Scrum is the most successful• Scrum is improved process framework in Agile Methodology where complex project can be
developed in complex environment.
• Scrum is lightweight process.
• Scrum follows three pillars of “Empirical Process” in perfect manner :» Inspection» Adaption» Transparency
• Scrum follows guidelines/rules and roles/responsibilities strictly to execute the program.
• Scrum can manage larger distributed teams in collaborative manner and build self-managing team
• Scrum build trust between team members.
• Scrum is event-driven process, so visibility is higher between the team members.
• Scrum is timebox-driven, so the team members are disciplined.
12
Scrum Terms• Product Backlog (subset of Product Backlog is “Release Backlog”)
– The Product Backlog is the requirements for a system, expressed as a prioritized list of Product Backlog Items (PBI). Owner : Product Owner
• Product / Release Burndown Chart– In Scrum, the product/release burn down chart is a “big picture” view
of a project’s success. It shows how much work was left to do at the beginning of each sprint. Release Burndown is updated at every sprint.
• The Sprint – “A time-box iteration of work during which an increment of product functionality is implemented. Sprint Length can vary between 1-4 Weeks. Maximum sprint length is 1 Calendar Month (or 30 Calendar Days)
• Sprint Backlog – Defines the work for a sprint , represented by the tasks associated with each PBIs committed to deliver by the team for the current sprint as in terms of their sprint goal. Owner : Team
• Sprint Burndown Chart – A sprint burndown chart depicts the total task hours remaining per day. Sprint Burndown Chart is updated on a daily basis by team.
13
Sprint 0The activities of Inception Phase (Pre-Starting Sprint Cycle Phase):
Develop Product Vision
Create Product Roadmap
Have common product vision with stakeholders agreement
Set Up Product Backlog with Defined Scope
Set Up Standard Architecture
Initial Release Planning
Form Initial Team and Educate Them for Agile Way Working
Set Up Work Environment
14
Scrum Process
15
Scrum Flow– Sprint Cycle
16
Timebox Events
Events/Meetings/ Ceremonies
Maximum Duration For 4-Weeks Sprint
Maximum Duration For 2-Weeks Sprint
Maximum Duration For 1-Week Sprint
Release Planning Not Defined Not Defined Not Defined
Sprint Planning 8 Hours 4 Hours 2 Hours
Daily Scrum 15 Minutes 15 Minutes 15 Minutes
Sprint Review 4 Hours 2 Hours 2 Hours
Sprint Retrospective 3 Hours 1.5 Hours 1.5 Hours
Backlog Refinement Reserves 5-10% of entire teams time during every sprint
17
Sprint Abnormal Termination
• Product Owner can ONLY cancel the sprint. Team may request to cancel.
• The reasons for cancellation of sprint :– Sprint Goal becomes obsolete.– Sprint Goal seems to be impossible to achieve.
18
Scrum Roles• Product Owner (PO)
– Accountable for product success – Defines all product features – Responsible for prioritizing the product features– Owns and Maintains the Product Backlog – Ensures team working on highest valued features– Accept/Reject the development work results– Responsible for Product Refinement Meeting– Responsible for maximizing ROI and increasing value of the product for
the customer– Decides Release Dates and to release working product into production
when there is a value to customer
19
Scrum Roles
• Scrum Master (SM)
– Make sure daily 15 minutes Daily Scrum Meeting happens– Remove impediments/roadblocks– Facilitating team decision and ensuring that team is
delivering value– Shields the team from external interference – Facilitate Scrum Ceremonies– Is a facilitator, not a manager– Servant Leader to Team, and to PO.
20
Scrum Roles
• What Scrum Master (SM) Should NOT Do
– Manage the team– Direct the team members– Assign Tasks– “Drive” the team– Make the decisions on behalf of team– Overrule the team members– Direct product strategy
21
Scrum Roles
• Development Team
– Team consists 3-9 People– Self-organizing, cross-functional team– Owns and maintains Sprint Backlog– Splits each PBIs into tasks breakout in the Sprint
Planning Meeting and estimates in hours– Responsible to manage themselves to achieve the
sprint goal
22
Scrum Roles @ High Level
• Scrum Master3Ps
– Problem Solver (Remove Impediments)– Process Owner (Educate Team/PO about Scrum Rules, Practices and Guidelines)– Protector (Shields Team from external interfaces)
• Product Owner Value Maximizer (Establish Product Vision, Prioritize Business Features and Maximize the value of
development work)
• Development Team Self-Organizer (Self-Managing, Self-Awareness and Volunteers their own task independently) Cross-functional (Multi-skilled team, Skills overlapping, crossing the boundary)
23
Scrum Artifacts
• Product Backlog (PB)
– List of all desired and prioritized product features, called ‘Product Backlog Items (PBIs)’; items are prioritized based on business value, risks and dependencies.
– List can contain features, bugs, improvements, technical requirements etc.
– Each item should have a business value assigned– Maintain by the Product Owner
24
Sample Product Backlog
User Story Card : As a <user>, I want to do <function>, so that <desired result>
ID Title Short Description Priority Business Value Story Points Status
RBS_US01
Daily maximum intraday liquidity stage
As a supervisor, I want to monitor a bank's intraday liquidity usage in normal conditions, so that I can make available the sufficient fund in the bank 1 High 8 Done
RBS_US02
Available Intraday liquidity at the start of the business day
As a supervisor, I want to monitor the amount of intraday liquidity a bank has available at the start of each business day, so that I can maintain the meeting its intraday liquidity requirements at normal conditions 1 High 8 Done
RBS_US03 Total Payments
As a supervisor, I want to monitor the overall scale of bank's activity, so that I can have clear visibility of payment records for each section 2 Medium 13 In-Progress
RBS_US04Time-specific obligations
As a supervisor, I want to gain better understanding of a time-specific obligation, so that I can clearly find out the settlement which fails to meet such obligations for financial penalty, reputational damage to the bank or loss of future business. 3 Low 20 To-Do
RBS_BUG01
Form labels are NOT properly aligned
Some of the form labels are center aligned, all of the form labels should be left-aligned. 3 Low 3 To-Do
25
Scrum Artifacts
• Sprint Backlog (SB)
– To-do list from PBIs for the sprint– Created by the Scrum Team – Selected product backlog items as per the priority
defined by PO.
26
Sample Sprint Backlog
ID Title Task Description Effort Estimation (In Hours)
RBS_US01
Daily maximum intraday liquidity stage
User Interface Design 8
Database Design 12
Coding 20
Code Review 10
Unit Testing 15
Automated Testing 15
Total Effort 80
27
Scrum Artifacts
• Burn down Chart
– Chart showing how much work remaining in a sprint
– Calculated in hours remaining– Maintained in daily basis by team
28
Sprint 1 Planning Meeting
Sprint Length : 4 Weeks
Sprint Start Date :
Sprint End Date:
Story TasksStart Hours
Hours Spent - Day 1
Hours Spent - Day 2
Hours Spent - Day 3
Hours Spent - Day 4
Hours Spent - Days 5
Hours Spent - Days 6
Hours Spent - Days 7
Hours Spent - Days 8
Hours Spent - Days 9
Hours Spent - Days 10
Hours Spent - Days 11
Hours Spent - Days 12
Hours Spent - Days 13
Hours Spent - Days 14
Hours Spent - Days 15
Hours Spent - Days 16
Hours Spent - Days 17
Hours Spent - Days 18
Hours Spent - Days 19
Hours Spent - Days 20
Total Hours
RBS_US01
Task1 20 0 0 0 0 2 2 2 0 2 0 0 2 0 2 2 2 2 2 0 0 20
Task2 40 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 40
Task3 32 3 1 0 2 0 0 1 3 0 2 2 2 2 2 2 2 2 2 2 2 32
Task4 20 2 0 2 2 2 0 0 0 0 0 0 0 0 0 2 2 2 2 2 2 20
Task5 30 1 3 1 2 2 2 1 0 0 0 0 0 0 6 2 2 2 2 2 2 30
Task6 14 2 2 1 8 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 14
RBS_US02
Task1 6 2 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 6
Task2 8 1 3 0 0 2 0 0 0 0 0 0 0 0 0 0 0 0 0 2 0 8
Task3 10 0 0 5 0 3 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 10
Actual Remaining Hours 180 167 155 143 126 111 105 99 94 90 86 82 76 72 60 50 38 28 18 8 0
Estimated Remaining Hours 180 171 162 153 144 135 126 117 108 99 90 81 72 63 54 45 36 27 18 9 0
Sample Data for Sprint Backlog Tasks
29
Sample Sprint Burn-down Chart
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 200
20
40
60
80
100
120
140
160
180
200
Sprint Burndown Chart
Actual Remaining Hours Estimated Remaining Hours
Sprint - Days
Rem
aini
ng W
orki
ng H
ours
30
Scrum Artifacts
• Increments
Potentially shippable functionalities which contains list of PBIs are delivered for current sprint combined with increments of all the previous sprints.
It must be working software which is in a consumable solution.
31
Scrum Meetings
• Sprint Planning Meeting
Day 1 – 1st Half
– Prioritized Product Backlog Items are shown by Product Owner
– Product Owner demonstrate the stories to Team– Team selects items committed to complete ; Sprint Goal
is defined by the Team with mutual agreement of PO.
32
Scrum Meetings
• Sprint Planning Meeting
Day 1 – 2nd Half
– Product Owner is available for team to clarify/answer the questions
– Team breaks out each items (or each stories) into the multiple tasks
– Tasks are created for each item and estimate in hours
33
Scrum Meetings
• Daily Scrum Meeting
– Holds everyday during a sprint at same time and same place
– Meeting should not exceed 15 minutes– Team member reports to each other, NOT Scrum Master– Three Questions to be answered by each team member
– What you have done since last daily scrum ?– What will you do before the next daily scrum ?– What are your impediments ?
– Opportunity to team members to synchronize their work
34
Scrum Meetings
• Sprint Review Meeting
– Team presents items are “Done” state to PO and Stakeholders
– Stakeholders provides the feedback to the team – Product Backlog may or may not be reprioritized based on feedback
– Items which are “NOT Done” are not shown– Scrum Master sets the next Sprint Review
35
Scrum Meetings
• Sprint Retrospective Meeting
– Attendees – Scrum Master, Team and Product Owner
– Team provides the opinions to below questions– What went well ?– What didn’t go well ?– What can be improved ?
– Scrum Master helps team in discovery – do not provide answers
36
Product Refinement Meeting
• The ‘Product Backlog Refinement’ which is also called as ‘Product Backlog Grooming’ in reference to keep backlog clean and orderly.
• This is a meeting should happen PO with the team held near to end of the sprint to make sure that backlog is ready for upcoming sprint.
37
Product Refinement MeetingProduct Backlog
Fine-grained requirements (High Priority)
small user stories
Medium-grained requirements (Medium Priority) larger user stories
Coarse-grained requirements (Low Priority)
A Epic
38
Product Refinement Meeting
DEEP Product Backlog is the result of Product Refinement Meeting
D – Detailed AppropriatelyE – EstimatedE – EmergentP – Prioritized
39
Prioritization
Prioritization Factors of PBIs
Business Value Risk Dependency Operational Emergency Due Date
Please Note that, “High Risk and High Value Features” should be completed faster.
40
Prioritization
Prioritization Techniques :
MoSCoW Techniques
Business Value-based
Technical Risk-Based
Kano Model
41
Definition of Done (DoD)
Product Backlog Item (PBI) DoD
• All acceptance criteria have been met• Automated accepted tests confirm that the new feature works as
expected.• All regression tests verify successful integration with other functions.• Any relevant build/deploy scripts have been modified and tested• Working functionality has been reviewed and accepted by PO.• End-user documentation has been written and reviewed (if required)
42
Definition of Done (DoD)
Release Level DoD
• All code related to release has been successfully deployed at the production service
• The release passes all production smoke tests
• Final release has been reviewed and accepted by Product Owner
• Customer and Marketing teams have been trained with the new feature
43
Stories, Themes and Epics
44
User Story
The user story is the atomic functionality of what the user wants to achieve by delivering the business value under system constraints. It can be derived under two domains: the business domain or the technology domain.
INVEST
INVEST is the techniques to have the best way to write an excellent user story. Here is what the acronym means:
I - Independent - The story should be independently identified -- that is, defined at the atomic level. It has no inherent dependency with another user story.
N - Negotiable - The user story can always be rewritten to respond to change.
V - Valuable - The story should always deliver the business value.
E - Estimable - The story should always be estimated in terms of size, in order to maintain the team's velocity.
S - Small - It should be small enough to complete within the iteration. If its size is big, the story must be broken down into smaller stories as much as possible.
T - Testable - The user story should follow test-driven development. Based on acceptance criteria, the test scripts should be developed first, before code is written, as the story should provide the necessary information to make test development possible.
45
User StoryThe 3 Cs of User Story
• The author of the user story can follow the "3 Cs" for writing a well-structured user story:
Card: As a <user>, I want to do <function>, so that I can achieve <business value>.
• Conversation: The detailed description of the story needs to be included. This means its step-by-step execution, basic flow and alternate scenarios, mock-up design, etc.
• Confirmation: This describes the acceptance criteria of the story. This means that the story is passed and accepted if the specific criteria for the story are in fact fulfilled in execution.
46
AGILE ESTIMATION TECHNIQUES
• T-Shirt Size Estimation
• Ideal Days Estimation
• Story Point Estimation
47
T-Shirt Size Estimation
T-Shirt Size Estimating
T-Shirt size estimating is a process by which stories are categorized as Small, Medium and Large. XL Stories are deemed too big to fit into an iteration and so need to be de-composed into smaller stories.
48
Ideal Days Estimation
• A unit for estimating the size of product backlog items based on how long an item would take to complete if it were the only work being performed, there were no interruptions/meetings (elapsed time) and all resources necessary to complete the work were immediately available.
• Ideal Days usually estimated in Hours for each PBIs.
49
Story Point Estimation• What is Story Point
– Story point is a arbitrary measure used by Scrum teams. This is used to measure the complexity of the story.
– Story is sized based on A. Business ComplexityB. Efforts C. Doubts or Risks
– Story point estimation is rough, relative and consistent.
– Story Point estimation removes unit confusion ; based on base story reference in terms of story points, other stories are fixed with their story points.
50
Story Point follows Modified Fibonacci Series
Story Point Estimation
51
Story Sizing Meeting with Planning Poker
• Each estimator selects a set of cards.• PO or Customer reads/explains the item to be estimated.• The item is discussed.• Each estimator privately selects a card representing his or her story size. The card is not shown to
the other estimators. Size = Complexity + Effort + Doubts or Risks• Once each estimator has selected a card, all cards are revealed at the same time.• If everyone played the same card, that’s the estimate.• If everyone played the different card, the group discussion happens on the especially on any
outlaying values.• Repeat until team comes to consensus (agree to support each other) on an estimate.
52
Agile Planning Onion
53
Release Planning Meeting• A very high-level plan for multiple Sprints (e.g. three to twelve
iteration) is created during the Release planning. • It is a guideline that reflects expectations about which features will be
implemented and when they are completed. • It also serves as a base to monitor progress within the project. Releases
can be intermediate deliveries done during the project or the final delivery at the end.
To create a Release Plan the following things have to be available:
– A groomed, prioritized and estimated Product Backlog– The (estimated) velocity of the Scrum Team– Conditions of satisfaction (goals for the schedule, scope, resources)
54
Release Planning MeetingVelocity :
• The story points that are supposed to be achieved by team at each iteration.
• Velocity can be determined by the below methods:
a. Determine the velocity range by historical data if the team is old and experienced for the past agile project delivery.
b. Run at least three iterations and calculate the average velocity for new agile team.
55
Release Planning MeetingFixed-scope planning
Fixed-scope planning means, “When will all the story points be achieved?”
There are three steps involved here :
• Add up the product backlog items (project size in terms of total story points).• Estimate velocity as a range or average.• Use the sum of the product backlog items divided by the velocity range or average to determine the date range or average
date of delivery of the project.
Fixed-date planning
Fixed-date planning means, “How many story points we can achieve by a given date?”
There are three steps involved in fixed-date planning as well:
• Determine how many iterations you have.• Estimate velocity as a range or average.• Partition the backlog into "must have," "might have," and "won’t have at this moment" items, according to the number of
items the team can work on (velocity) within each iteration.
56
From the above graph, 90% confidence level for team to achieve velocity is between 20 – 25 story points. So, the velocity range would be 20-25 Story
Points.
Velocity Range Determination on Historical Data
Sprint Velocity1 202 203 254 125 256 407 208 25
1 2 3 4 5 6 7 80
5
10
15
20
25
30
35
40
45
Historical Data on Velocity
Velocity
Release Planning Meeting
57
Release Burndown ChartTotal Project Size (In Story Points) 150
Iteration No. (Sprint No.) Velocity (In Story Points) Remaining Story Points
0 0 150
1 29 121
2 40 81
3 33 48
4 28 20
5 20 0
0 1 2 3 4 50
20
40
60
80
100
120
140
160 150
121
81
48
20
0
Release Burn-down Chart
Sprints
Rem
aini
ng S
tory
Poi
nts
0 1 2 3 4 50
20
40
60
80
100
120
140
160 150
121
81
48
20
0
Release Burn-down Chart
Sprints
Rem
aini
ng S
tory
Poi
nts
58
Release Burndown ChartTotal Project Size (In
Story Points) 150
Iteration No. Average Velocity (Estimated)
Accomplished Story Points (Velocity)
Remaining Story Points
1 30 29 1212 30 30 913 30 31 604 30 32 285 30 28 0
Release Burn-down Chart (X Axis: Remaining Story Points and Y Axis: Iteration No.)
59
Velocity ChartIterations No. of Story Points Accomplished
(Velocity)
1 202 223 134 255 30
1 2 3 4 50
5
10
15
20
25
30
35
Velocity Chart
No. of Story Points Ac-complished (Velocity)
60
Scaling Scrum – Scrum of Scrum (SoS)
• The primary way of scaling scrum to work with large teams is to co-ordinate a “Scrum of Scrum”
• With this approach each Scrum team proceeds as normal but each team also contributes a technical leader or representative who attends “Scrum of Scrum” meetings to co-ordinate the work of multiple scrum teams
61
Scaling Scrum – Scrum of Scrum (SoS)
• Top Three Dispersed Team Challenges in SoS :
Time Zone – The time differences across the globe challenges scrum meetings
Language – Various languages across the globe make communication barrier as common language understanding becoming more tougher
Culture- The culture across the globe, public holidays sometimes become challenges when large distributed team develop at cadence
62
Characteristics of High Performance Agile Team
• Has the right people• A committed and empowered team• Self-Organized Team• Has established trust between team members• Works at a sustainable pace• Reflects a consistent high velocity