Table of Contents
Introduction
Scrum is a software
development process. In today’s rapid world stakeholders want immediate return
on their investments. They don’t want to wait for longer periods to get full featured
product. As a result, nowadays new software development and testing
framework is
catching momentum i.e. Scrum approach.
In scrum, projects are
divided in small features to be developed and tested in specific time-frames
called as sprint (small cycles). Features should get
developed and tested in specified small time-frames. This agile scrum
team is handled by scrum master.
Scrum is an iterative, incremental framework for projects and
products or application development. Scrum has become more and more popular
software development and testing framework among organizations. Many small to
large sized IT companies have started to embrace Scrum framework, as this can
create excellent quality products in less
time than other
traditional methodologies. This framework can save companies both time and
money.
Pre-Requisite Soft Skills for a Scrum Team
Team Spirit
Cross functional Team work is at the heart of Scrum. There is no “my work”, “I have
finished my work” and “your work”. On a Scrum team we find only “Our work”,
“we have completed our Sprint”. Individuals will have helping
tendency for sharing technical knowledge. Scrum Members are always available to
team members rather than locked away behind closed doors. Scrum Master
will always motivate the teams and create a Supporting learning environment.
Team will always be sprint-oriented and often discuss smooth run of the sprint.
A scrum team’s job is to self-organize around the challenges and
management’s job is to remove impediments to self-organization.
Communication
Good communication must exist
among team members of development team, testing team, business analysts and
stake holders. There must be highly collaborative interaction between client
and the delivery teams. More client involvement implies more suggestions or
changes from the client. It implies more bandwidth for communication.
Commitment
Agile Teams needs periodic
re-energizing to renew their commitments to their purpose and to each
other. Scrum Masters can help by ensuring that the team embraces the
concept of whole-team responsibility and whole-team commitment to
deliver working software at the end of each sprint. With the whole-team
commitment, the team member who has completed his tasks will help the one who
has not completed so that hopefully each finishes on time.
Problem Solving
Scrum does not simply focus
on developing just any type of end product. Instead, the Scrum method
allows the team to focus on creating a product that fulfills the customer’s
highest value priorities which are defined by product owners.
Transparency
Transparency among team
members and management gives a real momentum to the scrum team. Scrum
Master encourages people to ask for help, surface roadblocks, and give public
recognition for those brave enough to do so. At the same time, Scrum Master
also understands the time wasted and impact on the team when individuals sit on
or ignore problems.
The Roles of Scrum
Scrum has three fundamental roles: Product Owner, Scrum Master, and team member.
- Product Owner: In Scrum, the Product Owner is responsible for communicating
the vision of the product to the development team. He or she must also
represent the customer’s interests through requirements and prioritization.
Because the Product Owner has the most authority of the three roles, it’s also
the role with the most responsibility. In other words, the Product Owner is the
single individual who must face the music when a project goes away.The tension
between authority and responsibility means that it’s hard for Product Owners to
strike the right balance of involvement. Because Scrum values self-organization
among teams, a Product Owner must fight the urge to micro-manage. At the same
time, Product Owners must be available to answer questions from the team.
- Scrum Master: The Scrum Master acts as a liaison between the Product Owner
and the team. The Scrum Master does not manage the team. Instead, he or she
works to remove any impediments that are obstructing the team from achieving
its sprint goals. In short, this role helps the team remain creative and
productive, while making sure its successes are visible to the Product Owner.
The Scrum Master also works to advise the Product Owner about how to maximize
ROI for the team.
- Team Member: In the Scrum methodology, the team is responsible for
completing work. Ideally, teams consist of seven cross-functional members, plus
or minus two individuals. For software projects, a typical team includes a mix
of software engineers, architects, programmers, analysts, QA experts, testers,
and UI designers. Each sprint, the team is responsible for determining how it
will accomplish the work to be completed. This grants teams a great deal of
autonomy, but, similar to the Product Owner’s situation, that freedom is
accompanied by a responsibility to meet the goals of the sprint.
The Core Process
Sprint Planning Meeting
The work to be performed in the Sprint is planned at the Sprint Planning
Meeting. This plan is created by the collaborative work of the entire Scrum
Team.The Sprint Planning Meeting is time-boxed to eight hours for a one-month
Sprint. For shorter Sprints, the event is proportionately shorter. For example,
two-week Sprints have four-hour Sprint Planning Meetings.
The Sprint Planning Meeting
consists of two parts, each one being a time-box of one half of the Sprint
Planning Meeting duration. The two parts of the Sprint Planning Meeting answer
the following questions, respectively:
- What will be delivered in the
Increment resulting from the upcoming Sprint?
- How will the work needed to
deliver the Increment be achieved?
Part One: What will be done in this Sprint?
In this part, the Development
Team works to forecast the functionality that will be developed during the Sprint.
The Product Owner presents ordered Product Backlog items to the Development
Team and the entire Scrum Team collaborates on understanding the work of the
Sprint. The input to this meeting is the Product Backlog, the latest product
Increment, projected capacity of the Development Team during the Sprint, and
past performance of the Development Team. The number of items selected from
the Product Backlog for the Sprint is solely up to the Development Team. Only
the Development Team can assess what it can accomplish over the upcoming Sprint. After
the Development Team forecasts the Product Backlog items it will deliver in the
Sprint, the Scrum Team crafts a Sprint Goal. The Sprint Goal is an
objective that will be met within the Sprint through the implementation of the
Product Backlog, and it provides guidance to the Development Team on why it is
building the Increment.
Part Two: How will the chosen work get done?
Having selected the work of
the Sprint, the Development Team decides how it will build this functionality
into a “Done” product Increment during the Sprint. The Product Backlog
items selected for this Sprint plus the plan for delivering them is called the
Sprint Backlog,The Development Team usually starts by designing the system and
the work needed to convert the Product Backlog into a working product
increment. Work may be of varying size, or estimated effort. However, enough
work is planned during the Sprint Planning meeting for the Development Team to
forecast what it believes it can do in the upcoming Sprint. Work planned for
the first days of the Sprint by the Development Team is decomposed to units of
one day or less by the end of this meeting. The Development Team
self-organizes to undertake the work in the Sprint Backlog, both during the
Sprint Planning Meeting and as needed throughout the Sprint. The Product
Owner may be present during the second part of the Sprint Planning Meeting
to clarify the selected Product Backlog items and to help make trade-offs. If
the Development Team determines it has too much or too little work, it may
renegotiate the Sprint Backlog items with the Product Owner. The Development
Team may also invite other people to attend in order to provide technical or
domain advice. By the end of the Sprint Planning meeting, the Development
Team should be able to explain to the Product Owner and Scrum Master how it
intends to work as a self-organizing team to accomplish the Sprint Goal and
create the anticipated Increment.
Sprint Goal
The Sprint Goal gives the
Development Team some flexibility regarding the functionality implemented
within the Sprint. As the Development Team works, it keeps this goal in mind.
In order to satisfy the Sprint Goal, it implements the functionality and
technology. If the work turns out to be different than the
Development Team expected,
then they collaborate with the Product Owner to negotiate the scope of Sprint
Backlog within the Sprint. The Sprint Goal may be a milestone in the larger
purpose of the product roadmap.
Daily Scrum
The Daily Scrum meeting is a 15-minute time-boxed event for the
Development Team to synchronize activities and create a plan for the next 24
hours. This is done by inspecting the work since the last Daily Scrum and
forecasting the work that could be done before the next one. The Daily Scrum is
held at the same time and places each day to reduce complexity. During the meeting,
each Development Team member explains:
- What has been accomplished since the last
meeting?
- What will be done before the next
meeting?
- What obstacles are in the way?
The Development Team uses the Daily Scrum to assess progress
toward the Sprint Goal and to assess how progress is trending toward completing
the work in the Sprint Backlog. The Daily Scrum optimizes the probability that
the Development Team will meet the Sprint Goal. The Development Team often
meets immediately after the Daily Scrum to re-plan the rest of the Sprint’s
work. Every day, the Development Team should be able to explain to the Product
Owner and Scrum Master how it intends to work together as a self-organizing
team to accomplish the goal and create the anticipated increment in the
remainder of the Sprint. The Scrum Master ensures that the Development Team has
the meeting, but the Development Team is responsible for conducting the Daily
Scrum. The Scrum Master teaches the Development Team to keep the Daily Scrum within
the 15-minute time-box. The Scrum Master enforces the rule that only
Development Team members participate in the Daily Scrum. The Daily Scrum is not
a status meeting, and is for the people transforming the Product Backlog items
into an Increment. Daily Scrums improve communications, eliminate other
meetings, identify and remove impediments to development, highlight and promote
quick decision-making, and improve the Development Team’s level of project
knowledge. This is a key inspect and adapt meeting.
Sprint Review
A Sprint Review Meeting is held at the end of the Sprint to
inspect the Increment and adapt the Product Backlog if needed. During the
Sprint Review, the Scrum Team and stakeholders collaborate about what was done
in the Sprint. Based on that and any changes to the Product Backlog during the
Sprint, attendees collaborate on the next things that could be done. This is an
informal meeting, and the presentation of the Increment is intended to elicit
feedback and foster collaboration. This is a four-hour time-boxed meeting for
one-month Sprints. Proportionately less time is allocated for shorter Sprints.
For example, two week Sprints have two-hour Sprint Reviews.
The Sprint Review includes the following elements:
- The Product Owner identifies what has been “Done” and what has
not been “Done”;
- The Development Team discusses what went well during the Sprint,
what problems it ran into, and how those problems were solved;
- The Development Team demonstrates the work that it has “Done”
and answers questions about the Increment;
- The Product Owner discusses the Product Backlog as it stands. He
or she projects likely completion dates based on progress to date; and,
- The entire group collaborates on what to do next, so that the
Sprint Review provides valuable input to subsequent Sprint Planning Meetings.
The result of the Sprint Review is a revised Product Backlog that
defines the probable Product Backlog items for the next Sprint. The Product
Backlog may also be adjusted overall to meet new opportunities.
Sprint Retrospective
The Sprint Retrospective is an opportunity for the Scrum Team to
inspect itself and create a plan for improvements to be enacted during the next
Sprint. The Sprint Retrospective occurs after the Sprint Review and prior to
the next Sprint Planning Meeting. This is a three-hour time-boxed meeting for
one-month Sprints. Proportionately less time is allocated for shorter Sprints.
The purpose of the Sprint Retrospective is to:
- Inspect how the last Sprint went with regards to people,
relationships, process, and tools;
- Identify and order the major items that went well and potential
improvements; and,
- Create a plan for implementing improvements to the way the Scrum
Team does its work.
The Scrum Master encourages the Scrum Team to improve, within
the Scrum process framework, its development process and practices to make it
more effective and enjoyable for the next Sprint. During each Sprint
Retrospective, the Scrum Team plans ways to increase product quality by
adapting the Definition of “Done” as appropriate. By the end of the Sprint
Retrospective, the Scrum Team should have identified improvements that it will
implement in the next Sprint. Implementing these improvements in the next
Sprint is the adaptation to the inspection of the Scrum Team itself. Although
improvements may be implemented at any time, the Sprint Retrospective provides
a dedicated event focused on inspection and adaptation.
Development
and testing goes hand in hand
Case Study for Agile / Scrum Process
Quality Assurance activities in Scrum
Scrum is a management methodology. It has some important rules and practices for management, and management can get help to
organize and better handle their processes by using this methodology. So, it is
not an engineering process with some defined quality assurance activities.
Management can introduce any activities by their own to get a quality product.
Dr. Ralph van Roosmalen says that, Scrum is a framework for project management
and it does not contain any help for testing or development practices. Mostly companies
working in Scrum use its combination with XP(Xtreme Programming). In this way
Scrum assist in the project management and the practices of Xp are used to
guide development.
Working step in Scrum are:
- Unit testing
- Continuous integration
- Regular sprint meeting
- Regular daily meeting
- Strict to coding and design standard
- Acceptance testing
- Test automation
- Exploratory Testing
Iterative
lifecycle and frequent communication are the important aspects of SCRUM for a
tester. There two require some adjustments from the tester’s side, and they can keep the some things in mind. Testing of the
product is done during the iteration and not at the end of the development life
cycle. It is the duty of the tester to decide that what to test when the
product is still unfinished. Scrum is all about working as a team, and
collaboration is the basic idea. So, for a tester it is highly recommended that
he/she must work closely with other team members rather then working in
isolation. Testers should be given an active participation in the daily meeting
and a tester should be present at daily status meetings that and it is maximum
of 15 minutes long. For a tester perspective it is worthy and quality oriented
if he/she works with other testers and figures out that what to test, instead
of testing from the requirements documents.
Best practices for Agile
Testing process
- Integrate the testers in the development teams
Teams are
responsible for delivering software that meets expected requirements and
quality. However, if we want teams to test the software, we must give them the
knowledge to do it right. Testers have that knowledge. By integrating testers
into the development teams, teams obtain the skills they need to test their
software. When you try this, make sure you choose the right mix: one tester on
three programmers is a fair but minimal number.
- Use risk based testing
You can
never test everything with the same (extensive) depth; even in a waterfall
project you have to make choices. In an agile project all the activities are
time boxed so you have to make choices about how extensively you want to test
each feature. We use a risk based approach to determine which test activities
we are going to carry out for a feature during the iteration. The risk level of
every feature is determined by the customer and the teams. It is a very
transparent process so the customer knows exactly which test activities are
executed for every feature.
- Have testers review unit tests
In our
organization the developers are responsible for creating and maintaining the
unit tests. Unit tests are a very important part of our test harness.
Developers often have a different way of thinking; for example, they tend to
test only the success scenario. To create unit tests that are as good as
possible, our testers review the unit tests for all our high-risk items. The
review has two advantages. First, the unit tests are improved because testers
and developers supplement each other: the developer knows where the weak places
in the source are, and the tester can use his knowledge of testing to give tips
to improve the unit tests. Second, the testers know exactly which test cases
are executed in the unit tests and can concentrate on executing other (e.g.
higher-level) test cases.
- Create a test automation framework and
appoint a tool smith
Automated
testing is very important because new features and refactoring can introduce
problems that can be difficult to find. By using an automated test framework,
we can maintain quality levels during the iteration. Our testers are able to
create new tests easily and quickly in the framework. We have a dedicated test
engineer (we call him a tool smith) that maintains and optimizes the test
automation framework, reviews the new automated tests of the testers and
analyzes the daily test results. Testers in the teams can spend more time
creating and extending automated tests because the tool smith supports them.
- Display
quality metrics in a public location
Almost
every software project has a problem registration system, automated test
results, and in some cases nightly or continuous build results. But how often
do team members look at the results or count the open problems? We installed a
monitor in the coffee room that displays the actual metrics of the currently
open problems, the percentage of successful unit tests, the percentage of
successful nightly builds, and the current state of the continuous build. By
displaying the metrics in public the teams are confronted with the information.
The information is no longer just a number in a system or a record with some
information in a metrics database.
- Add a test scrum
One
advantage of having a separate test team in one room is that the communication
between the testers is good. When you have a project like ours where the
testers are distributed across several teams, the communication becomes more
difficult. To solve this problem, we use a test scrum to align the test
activities. Our test scrum is held twice a week and every team is represented
by one tester. The test scrum is a scrum like the daily team scrum but focused
on test activities. The test manager is the scrum master of the test scrum.
- Implement test retrospectives
Every
team in our project holds a retrospective meeting at the end of the iteration.
In the retrospective, the team discusses the process: what went well and what
went wrong. The testers in the team learn and discover new ways to improve
their tests; it is good when they share this knowledge with testers from the
other teams. We have a test retrospective every iteration so the testers can
exchange knowledge and experience and discuss problems they have. It is
important that the retrospective is only related to test issues; you shouldn’t
discuss team issues (they should be discussed in the team retrospective). As
with the test scrum, the test manager is the scrum master of the test
retrospective.
- Plan open problems
We try
to fix all the problems that we find during the iteration in that same
iteration, but sometimes we end the iteration with open problems. The best way
to handle those problems is to add those problems to the sprint backlog for the
next iteration. By explicitly planning those problems, the chance that they are
“forgotten” and pile up is very small.
- Remember: Testing is still testing
When you
test in an agile software project you can still use the “traditional” test
techniques. We use exploratory testing but also apply test techniques such as
boundary value analysis, equivalence partitioning, cause/effect diagram, and
pair-wise testing. Which test techniques we choose for a feature depend on its
risk category. Exploratory testing is used in every category; but if the risk
is higher we also apply more formal test techniques. The challenge for the
tester is to use a formal test technique without delivering extensive test
documentation.
- Start doing it!
The last but
most important tip is start doing it! Don't talk too much about how you are
going to introduce testers, or which test approach is perfect for your
organization. You are going to make mistakes or discover that the chosen
approach doesn’t fit your organization. That’s a given. But, the sooner you
start, the sooner you can begin learning and improving your test approach. With
the retrospective meetings, you have the opportunity to adapt your test
approach every month.
