Traditional software development models (such as Waterfall) are based upon a defined methodology which attempts to define requirements up front, logically break down the work estimate plan then begin development while trying to SCRUM – How It Differs work, estimate, plan, development, limit/control change which will threaten the plan. These are based upon Defined Process Model theory which was adopted from manufacturing and applied to software development.

1. Scrum, Agile Process
Sumit Sinha CSM®
Software Business Analyst

2. Scrum
• Scrum is an agile process that allows us to focus on
delivering the highest business value in the shortest
time.
• It allows us to rapidly and repeatedly inspect actual
working software (every two weeks to one month).
• The business sets the priorities. Teams self-organize to
determine the best way to deliver the highest priority
features.
• Every two weeks to a month anyone can see real
working software and decide to release it as is or
continue to enhance it for another sprint.

3. Scrum Characteristics
• Self-organizing teams
• Product progresses in a series of month-long
“sprints”
• Requirements are captured as items in a list of
“product backlog”
• No specific engineering practices prescribed
• Uses generative rules to create an agile
environment for delivering projects
• One of the “agile processes”

4. Scrum

5. Scrum Framework
Roles
•Product owner
•ScrumMaster
•Team
Ceremonies
•Sprint planning
•Sprint review
•Sprint retrospective
•Daily scrum meeting
Artifacts
•Product backlog
•Sprint backlog
•Burndown charts

6. Product Backlog
• The requirements / list of
test cases
• A list of all desired work
on the project
• Prioritized by the product
owner
• Reprioritized at the start
of each sprint
• Participant: Product Owner
TThhiiss iiss tthhee pprroodduucctt bbaacckklloogg

7. Product Backlog
In automation product backlog will be:
• Quality Center
– Is the repository of all test cases for Stars Enterprise application
– Contains all the test steps for all test cases
– Test cases don’t have importance or priority ratings
– List of test cases will be exported to Excel for easier prioritization
and estimation
• Excel spreadsheet
– List all the test cases that need to be automated
– Test cases have importance or priority ratings
• Importance rating is numeric
– Used in sprint planning and determines the sprint backlog

8. Sprint Planning
• Team selects items from the
product backlog they can commit
to completing
• Sprint backlog is created
• Tasks are identified and each is
estimated
• Collaboratively, not done alone by
the Scrum Master
• Define the sprint length and the
sprint demo date
PartiProduct Owner, Scrum Master,
and Team

9. Sprint Backlog
• A list of requirements or
test cases that the team
is committing to complete
in the current sprint.
• Items on the sprint
backlog are drawn from
the product backlog
• Contains the team’s time
estimate to complete the
various test cases
• This will be used to set
the project plan

10. Managing the Sprint Backlog
• Estimated work remaining is updated daily
• Any team member can add, delete or change the 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
• This will be kept in a shared directory for everyone to
update

11. Sprint
• Scrum projects make
progress in a series of
“sprints”
• Analogous to Extreme
Programming iterations
• Typical duration is 2–4 weeks
or a calendar month at most
• A constant duration leads to a
better rhythm
• Automated scripts are
designed, coded, tested and
code reviewed during the
sprint
Participant: Team

12. Daily Scrum
• Parameters
• Daily
• 15 minutes
• Stand-up
• Not for problem solving
• Whole world is invited
• Only team members, Scrum
Master, product owner, can talk
• Helps avoid other unnecessary
meetings
• Each participant answers the
following questions:
• What did you do yesterday?
• What will you do today?
• Is there anything on your way?
• NOT a Status meeting

13. Sprint Review
• Team presents what it
accomplished during the sprint
• Typically takes the form of a
demo
• Informal
• No slides
• Whole team participates
• Executes the existing
regression test scripts and the
newly created scripts against
the latest build of the
application.

14. Sprint Retrospective
• Periodically take a look at
what is and is not working
• Typically 15–30 minutes
• Done after every sprint
• Whole team participates
• Scrum Master
• Product owner
• Team
• Possibly customers and
others
• Discuss the following:
• Start doing
• Stop doing
• Continue doing

15. Thank You!
Name : Sumit Sinha
Contact : sumitrsinha@gmail.com
https://www.linkedin.com/pub/sumit-sinha-csm%C2%AE-iim-calcutta/19/aa5/78a