Unit :2

Agile SCRUM Framework

 What is Scrum?
• Scrum: It’s about common sense
– Is an agile, lightweight process
– Can manage and control software and product development
– Uses iterative, incremental practices
– Has a simple implementation
– Increases productivity
– Reduces time to benefits
– Embraces adaptive, empirical systems development
– Is not restricted to software development projects

– Embraces the opposite of the waterfall approach…

2
 Scrum at a Glance

24 hours
Daily Scrum
Meeting

Backlog tasks 30 days

expanded
Sprint Backlog by team

Potentially Shippable
Product Backlog Product Increment
As prioritized by Product Owner
Source: Adapted from Agile Software
Development with Scrum by Ken
Schwaber and Mike Beedle.

3
Project phases

4
 Agile Estimations
Agile estimation techniques are collaborative. All appropriate
people are included in the process.
For example the whole Scrum team participates in estimating
effort of Product Backlog Items.
Most Agile estimation techniques use relative units. This means
that we don’t try to estimate dollars or days directly.
Instead, we use “points” or even qualitative labels and simply
compare the items we are estimating to each other.
Gross-level estimation techniques are in use by teams using agile
approaches such as Scrum and Extreme Programming, and this
will cover two of the most popular techniques:
1.Planning Poker
2.T-shirt sizing
5
Planning Poker
•In this Estimation technique, all the people who are supposed to do the estimations,
sit in a round circle for the Planning Poker session.
•Each estimator is having a set of Planning Poker Cards of values: 0,1,2,3,5,8,13,20,40
and 100. These values represent story points or measure in which the team estimates.
•At the start of the session, the product owner or customer reads out the user story,
describing all its features and requirements.
•After the story is read out, the discussions among the estimators and with the
product owner/customer take place. The estimators can ask questions or clarify their
doubts with the product owner.
•After the discussions, all estimators are asked to select one card to estimate a user
story. If all estimators give same value, then that becomes the final estimate.
•If values are different then the estimators giving highest and lowest values explain
their opinions and why they chose this value, until a consensus is achieved.
•A good technique when small no. of items is to be estimated in a small team.

6
T-shirt sizes
•Just as in the case of T-shirts, we see sizes: XS (Extra Small), S (Small), M
(Medium), L (Large), XL (Extra Large). A similar approach is followed here.
Items are estimated in T-shirt sizes.
•This is a perfect technique to give a rough estimation of the large backlog of
items.
•Useful when quick and rough estimation needs to be done. Later these sizes
can be converted into no’s as per the requirement.
•A relative size (mostly Medium) is decided after mutual discussion and
agreement of the team members or estimators. Then, the no’s are assigned
to the items according to the relative size that is assigned to Medium size.
•Disadvantage: What seems L to someone may seem to be XL for
someone.
•All estimators assign their own size to the items. After discussions and
resolving the mismatches, a consensus is reached to get the final estimate.

7
 Sequential vs. Overlap
Requirements Design Code Test

Rather than doing all of one

thing at a time...
...Scrum teams do a little of
everything all the time

8
 Planning game
Developers had to invent a planning method that would combine the efficiency of
traditional project planning with the specific features of the methodology relied to the
customer’s involvement into the working process. When such a method of planning
was invented it was called the Planning Game. Planning game involve:
Step 1: Creation or selection of the story
•At this stage, the customer must create certain user story or select it from his list. Such stories
will be analyzed and prioritized during the Planning Game. They will formulate the basis of the
future project’s plan.
Step 2: Story estimation
•This stage of the Planning Game is conducted by the team of developers. They must estimate
the story in accordance with the criteria of time and costs required for its realization.
Step 3: Prioritization of stories
•This is the beginning of the project’s plan. At this stage of the Planning Game, the customer
places the estimated user story into the plan. All stories are prioritized in accordance with his
requirements to the final product.
Step 4: The process is repeated
•After one story is estimated and prioritized in the project’s plan the process is repeated until the
plan is completed.

9
 iteration planning
Iteration planning is the process of discussing and planning the
next cycle, phase or iteration of a software application that is
under development.
It is conducted through a meeting of the entire software
development team at the starting point of each iteration to
formally plan technical and non-technical processes.
Iteration planning is also known as iterative planning.
During the iteration planning process, input is received from a
previous iteration or the project kickoff phase, including a
source code overview of previously developed components,
release notes, a list of bugs/results and software test results.
Generally, the complete iteration planning process is managed
by the software development manager or project manager and
later articulated as an iteration plan. 10
 Acceptance tests and verifying stories

 Acceptance Testing is the process that verifies if the installed piece of code or
software works as designed for the user.
 It is a validation activity that uses test cases which cover scenarios under which the
software is expected to be used and is conducted in a ‘production-like’ environment
on hardware that is similar to what the user or the customer will use.
 Acceptance Tests assert the functional correctness of the code and hence contain
detailed specifications of the system behavior in relation to all meaningful scenarios.
 Acceptance Tests check the reliability and availability of the code using stress tests.
 This also checks the scalability, usability, maintainability, configurability and security
of the software being developed and determines whether a developed system
satisfies the Acceptance Criteria and checks if the user story is correctly
implemented.
 Acceptance Tests can be written in the same language as the code itself.
 This testing is of two types:
a) Customer Acceptance Testing – Where the customer does the testing.
b) Beta Testing or User Acceptance Testing – Where the end users test the product.

11
 Verifying stories
Are we making the product right?
Are we correctly building the solution?
Verification is testing that your product meets the specifications / requirements you
have written. "Did I build what I said I would?".
Failure to answer above questions positively throughout development can result in
delivering a defective solution.
Failure to verify the solution at each level of construction can result in costly, thrown-
away work and backtracking to redesign, rewrite specifications, or redevelop solution
components.
Verify each and every user story and the product is verified in chunks toward the
solution's deployment.

12
 Project velocity
 Velocity is an extremely simple, powerful method for accurately measuring the rate
at which scrum development teams consistently deliver business value.
 To calculate velocity of your agile team, simply add up the estimates of the features,
user stories, requirements or backlog items successfully delivered in an iteration.
 Along with release and iteration burndown charts, measuring the velocity of agile
teams has proven to provide tremendous insight/visibility into project progress and
status.
 A velocity chart shows the sum of estimates of the work delivered across all
iterations.

13
 Scrum Framework
Roles
•Product owner
•Scrum Master
•Team Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts
14
 Scrum Roles
– Product Owner
• Possibly a Product Manager or Project Sponsor
• Decides features, release date, prioritization, $$$

– Scrum Master
• Typically a Project Manager or Team Leader
• Responsible for enacting Scrum values and practices
• Remove impediments / politics, keeps everyone productive

– Project Team
• 5-10 members; Teams are self-organizing
• Cross-functional: QA, Programmers, UI Designers, etc.
• Membership should change only between sprints

15
 Sprint Planning Mtg.
Team
Sprint planning meeting
Team
capacity
capacity
Sprint prioritization
Product
Product
• Analyze/evaluate product Sprint
Sprint
backlog goal
backlog
backlog goal
• Select sprint goal
Business
Business
conditions
conditions Sprint planning
• Decide how to achieve sprint goal
(design) Sprint
Current
Current
• Create sprint backlog (tasks) from
Sprint
product
product
product backlog items (user stories backlog
backlog
/ features)
Technology
Technology • Estimate sprint backlog in hours
16
 Daily Scrum Meeting
• Parameters
– Daily, ~15 minutes, Stand-up
– Anyone late pays a some fee

• Not for problem solving

– Whole world is invited
– Only team members, Scrum Master, product owner, can talk
– Helps avoid other unnecessary meetings

• Three questions answered by each team member:

1. What did you do yesterday?
2. What will you do today?
3. What obstacles are in your way?
17
 Scrum's Artifacts
• Scrum has remarkably few artifacts
– Product Backlog
– Sprint Backlog
– Burndown Charts

• Can be managed using just an Excel spreadsheet

– More advanced / complicated tools exist:
• Expensive
• Web-based – no good for Scrum Master/project manager who travels
• Still under development

18
 Product Backlog
• The requirements

• A list of all desired work on project

• Ideally expressed as a list of user

stories along with "story points",
such that each item has value to
users or customers of the product

This
This is
is the
the • Prioritized by the product owner
product
product backlog
backlog
• Reprioritized at start of each sprint

19
 User Stories
• Instead of Use Cases, Agile project owners do "user stories"
– Who (user role) – Is this a customer, employee, admin, etc.?
– What (goal) – What functionality must be achieved/developed?
– Why (reason) – Why does user want to accomplish this goal?

As a [user role], I want to [goal], so I can [reason].

• Example:
– "As a user, I want to log in, so I can access subscriber content."

• story points: Rating of effort needed to implement this story

– common scales: 1-10, shirt sizes (XS, S, M, L, XL), etc.

20
 Sample Product Backlog
Backlog item Estimate

Allow a guest to make a reservation 3 (story points)

As a guest, I want to cancel a reservation. 5

As a guest, I want to change the dates of a reservation. 3

As a hotel employee, I can run RevPAR reports (revenue-

8
per-available-room)

Improve exception handling 8

... 30

... 50
21
Sample Product Backlog 2

22
 Sprint Backlog
• Individuals sign up for work of their own choosing
– Work is never assigned
• Estimated work remaining is updated daily

• Any team member can add, delete change sprint backlog

• Work for the sprint emerges
• If work is unclear, define a sprint backlog item with a larger
amount of time and break it down later
• Update work remaining as more becomes known

23
 Sample Sprint backlog

Tasks
Tasks Mon
Mon Tue
Tue Wed
Wed Thu
Thu Fri
Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the Foo class 8 8 8 8 8
Add error logging 8 4

24
 Sprint Burndown Chart
• A display of what work has been completed
and what is left to complete
– one for each developer or work item
– updated every day
– (make best guess about hours/points completed each day)

• variation: Release burndown chart

– shows overall progress
– updated at end of each sprint

25
Hours Sample Burndown Chart

26
 Tasks
Tasks Mon
Mon Tue
Tue Wed
Wed Thu
Thu Fri
Fri
Code the user interface 8 4 8
Code the middle tier 16 12 10 7
Test the middle tier 8 16 16 11 8
Write online help 12

50
40
30
Hours

20
10
0
Mon Tue Wed Thu Fri

27
 Agile Project Management Tool

JIRA
JIRA is a tool developed for bug tracking, issue tracking and project
management to software and mobile development processes. The JIRA
dashboard has many useful functions & features which are able to handle
different issues easy. Some of the key features and issues: issue types,
workflow’s, screens, fields, issue attributes. Some of the features you won’t find
elsewhere. The dashboard on JIRA can be customized to match your business
processes.

OpenProject
OpenProject is a powerful open source project management tool that is notable for its
ease of use and rich project management and team collaboration features.
Its modules support project planning, scheduling, roadmap and release planning, time
tracking, cost reporting, budgeting, bug tracking, and agile and Scrum. Its agile features,
including creating stories, prioritizing sprints, and tracking tasks, are integrated with
OpenProject's other modules.
OpenProject is licensed under GPLv3 and its source code is available on GitHub.

28
Scrum vs. Other Models

29
Thank You

30