The Ultimate Test Automation Guide_ Best Practices and Tips.pdf
Agile scrum training
1. Agile & Scrum- An Introduction
Prepared and Presented by
Rajakrishnan S – MCA,MBA,PMP,CSM,ISTQB(Advanced),ITIL
2. Purpose of this Session
● To go through the Agile practices
● To go through the Scrum Method
3. Agenda
● What is Agile and its principles (20 minutes)
● When to use agile
● When to not use agile
● Agile pros and cons
● Scrum (40 minutes)
● Components of Scrum
● Estimation in Scrum
● Requirements Management in Scrum
4. What is Agile
● Iterative and Incremental development Model
● Time boxed iterative approach
● Encourages rapid and flexible response to change
● Self organizing and cross-functional teams
● Aim to delivery right product, at right price in right time
● Core values include
● Adaptability
● Transparency
● Simplicity
● unity
5. Agile Manifesto
● Individuals and interactions over processes and tools
● Working software over comprehensive documentation
● Customer collaboration over contract negotiation
● Responding to change over following a plan
That is, while there is value in the items on the right, we value the
items on the left more.
6. Agile Manifesto...
● Individuals and Interactions –
- in agile development, self-organization and motivation are important, as are
interactions like co-location and pair programming.
● Working software –
– working software will be more useful and welcome than just presenting
documents to clients in meetings.
● Customer collaboration –
– requirements cannot be fully collected at the beginning of the software
development cycle, therefore continuous customer or stakeholder
involvement is very important.
● Responding to change –
– agile development is focused on quick responses to change and continuous
development.
7. When to use Agile
● Requirements are not complete
● There are changes in requirements expected
● Quick customer releases with high quality is the objective of the
organization
● Customer collaboration is possible
● When feature development heavily relies on stakeholders feedback
8. When to not use Agile
● Application users(Stakeholders) are NOT always accessible to you.
● You need to follow traditional software management processes and
procedures.
● Deliverable must pass through a chain of approvals and tollgates
● You have to formally document the requirements, design, code, and
testing cases during each phase of the software life cycle.
● Don’t try agile it you already decided against it :)
9. Pros and Cons of Agile
● Pros
● Early and frequent delivery of business value hence satisfied
stakeholders/customers
● More flexible than traditional model
● Involvement of QA throughout the process
● More visibility to each team member, increases motivation and
ownership
● More accuracy in estimation, since working in chunks
● Early feedback/acceptance of customer is possible
● Responsive to changes
10. Pros and Cons of Agile
● Decreases risks by having working software
● Increased control
● Less barriers in communication
● Small releases, easy to manage
● Cons
● Over-hype about agile will lead to lot of unrealistic expectation
● Approach of the people
11. Some Factors to succeed in
Agile
● Dedicated product manager
● Experienced and self organized team
● Automation testing and developer testing
● Attitude towards scrum
● Adaptive to changes
● Readiness to do face-face communication
● Management Support
12. Various Agile Methods
● SCRUM
● Kanban
● Extreme Programming
● Agile Unified Process
● Feature Driven Development
13. Some of the major users of Agile
Google
Microsoft
Oracle
Dell
FIFA (Accepted as the official training process)
..
..
..
15. What is Scrum
● Scrum is an agile approach to Software Development
● Scrum is an iterative and incremental development process
● The project is split into a series of consecutive iterations (sprints)
● Scrum is a framework rather than a full process or methodology
● Scrum relies on self-organizing and cross-functional team
● Scrum teams are supported by Scrum Master and Product Owner.
There is no overall leader
16. History of Scrum
● Scrum (in rugby) to restart the game in situation when ball has
gone out of play
● 1986- Hirotaka and Ikunjiro described a new approach to product
development that would increase the speed and flexibility. They
called it a rugby approach, where a cross functional team work
together as a unit to reach the distance
● In 1990s: Ken Schwaber and Jeff sutherland used similar approach
and used the term scrum
● 1995: Sutherland and Schwaber presented a paper on scrum
methodology for the first time in Austin, Texas
20. Sprint (Iteration)
● Scrum Projects make progress in a series of sprints
● Each sprint(Iterations) no more than a month long
● Team members commit to deliver some number of features from
product backlog
● Features are coded, tested and integrated to the product or system
● Sprint Review Meeting is conducted at the end of the sprint and
each team demonstrates the new functionality to product owners
and other interested stakeholders
21. Product Owner
● Product Owner represents the business, customers and users
● Guides the team towards building the product.
● He is often someone from Product Management or Marketing, a
key stakeholder or a user
22. Scrum Master
● Scrum Master can be thought of as a coach/facilitator for the team
● The Scrum Master is responsible for making sure the team is as
productive as possible
● Helps team to use the scrum framework to perform at their highest
level
23. Scrum Team(Engineering Team)
● “We are all in this together”
● Scrum doesn’t include any of the traditional software engineering
roles such as programmer, designer,tester, or architect
● A typical scrum team is 6-10 in size
24. Product Backlog
● It’s a prioritized master list of all features(called stories) desired in
the product
● The Product Backlog is allowed to grow and change as more is
learned about the product and its customers.
● Product owner owns the product backlog
25. User Stories
● Requirements are captured in scrum as user stories
● A user story is a tool used in Agile software development to capture a description of
a software feature from an end-user perspective. The user story describes the type
of user, what they want and why. A user story helps to create a simplified
description of a requirement
● User Stories are pointers, and the details of stories can be provided in any
format(like requirement documents, wireframes etc..)
● Format :As a <type of user>, I want <some goal> so that <some reason>.
● Example: As a power user, I can specify files or folders to backup based on file size,
date created and date modified.
●
26. Sprint Backlog
● It’s the list of tasks that the Scrum team is committing for the
current sprint
● Items are selected from product backlog based on the priority set
by product owners and the perception on the team
● It can be maintained in an excel sheet or in tools like JIRAAgile,
TFS, scrumworks, version1 etc.
● Each product backlog items selected for the current sprint will be
added by expanding those with tasks and estimating hours
● The estimated work remaining in the sprint is calculated daily and
graphed, resulting in a sprint burn down chart
29. Sprint Planning Meeting
● The meeting to plan the items to be delivered in the sprint
● Attended by Product Owner, Scrum Master, the entire scrum team,
Any other interested management or customer representatives
● Product owner describes Objective of the sprint and the highest
priority stories to the team
● 4 hours time limit for a 2 week sprint
30. Daily Scrum Meeting
● The team hold a daily stand up meeting.
● Typically held in the same location and same time
● Team members who has committed to tasks will only talk
● Its not a problem-solving or issue resolution meeting
● Issues raised are taken offline and usually dealt with by the relevant
subgroup immediately after the daily scrum
31. Daily Scrum Meeting...
● During the scrum each team members provides answer to the
following questions
● What did you do yesterday?
● What will you do today?
● Are there any impediments in your way?
● 15 Minutes time limit for each team
● This is not a status update meeting in which boss is collecting
information about who is behind schedule
● It’s a meeting in which team members make commitments to each
other
32. Daily Scrum Meeting-
Role of a scrum master
● Its scrum master’s responsibility to resolve the impediments raised
in the meeting
● If scrum master cannot resolve it directly(technical issues), he
should make sure that someone in the team does quickly resolve
the issue, by taking the responsibility.
33. Daily Scrum Meeting-
Sample Impediments
● My ____ broke and I need a new one today.
● I need help debugging a problem with ______.
● I'm struggling to learn ______ and would like to pair with someone
on it.
● The department head has asked me to work on something else "for
a day or two."
● The environment is not ready to test
● The delivery of the item is getting delayed from ‘X’
34. Sprint Review Meeting(Exit Demo)
● Sprint Review Meeting is held at the end of each sprint
● Scrum teams shows what they have accomplished (Demo of new
features)
● Its very informal with rules avoiding the use of power point slides
and allowing no more than 2 hours of preparation time for the
meeting
● Sprint review meeting should be a natural result of the sprint
35. Sprint Review Meeting…
● Participants
● Product Owner
● The Scrum team
● Scrum Master
● Management
● Customers
● and Developers from other projects
● Project is assessed against the sprint goal determined during the
planning meeting
● Its important that team achieve the goal of the sprint
● 2 hours is the limit for a 2 weeks sprint
36. Sprint Retrospective
● All team members reflect on the past sprint
● Make continuous process improvements
● Main questions asked in the sprint retrospective are:
● What went right during the sprint
● What went wrong during the sprint?
● What could be improved in the next sprint?
● 1 hour is the time limit
37. Daily Scrum Meetings – Best Practices
● Stand up means stand up, no sitting, really
● Keep it short. 15 minutes max.
● Stand in front of the visual progress artifact
● Everybody should be present.
● No typing
● Concentrate on the second and third question, not on the first one.
● If team talks too much to Scrum Master, let him not too look at the team.
.
38. Requirements in Agile-Scrum
● Requirements are captured in the form of user stories
● User story has the following format
● As a <Actor>, I want to <Do this>, So I can <get this>
● Example: As a User, I want to log in, So I can access subscriber
content
● These user stories will be elaborated by the team along with the
product owner(customer representative)
39. Estimation in Agile-Scrum
● There are different estimation techniques in Agile-Scrum
● Planning Poker(Fibonacci Series-1,2,3,5,8,13,21)
● Power of 2(2,4,8..)
● T-shirt sizing (X-Small, Small, Medium, Large, X-Large)
40. Definition of Done
● Self review of code should be completed with the help of automated tools
● Code/Config should be reviewed
● Unit testing with coverage of 80% and above
● Developer Sanity testing(All Acceptance cases) should be completed in Dev
env.
● Story Level Functional Test cases should be reviewed
● Test execution should be completed in QA environment
● All defects are closed
● Acceptance criteria should be met
● Demo to the Product Owner
● Signoff from Product Owner
● All tasks related to the story should be closed in optimus
● Deployment instructions are documented
41. Measuring Agility
● Velocity of the team can be used to measure the agility
● Velocity tells how much the team can delivery
● Velocity is calculated as an average
● Example of Velocity: 40 story points per sprint by the 5 member
team
42. Some Best Practices
● Early demo to PO
● Design(specially UI) can be demoed to the PO to get an early
feedback by the developer
● Once feature is developed in developer environment, a demo
can be done to the PO
● Test Scenarios/Cases can be reviewed by PO and peer
developer
● Buddy Testing
● Tester work with developer to validate the story in developer
environment prior to deploy in QA env.
43. For Further Reference
● http://www.agilealliance.org/
● Http://www.wikipedia.org
● http://agilemanifesto.org/
● http://www.agilemanifesto.org/principles.html
