How to use your QA Skills in a Scrum-Based Project Part I

What is Agile Development?

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle (Wikipedia).
Before the Agile methodology, methods of software development tended to be slow, bureaucratic and inconsistent. This created the need for a more adaptive method of software development.   A large number of IT project failures lead toward a new way of thinking and delivering the project:  IT teams around the world adapting the new ideas and getting them to work and deliver the success to their respective clients.
Agile methodologies encourage teamwork, self-organization, and accountability. Most agile development teams comprise 5-9 team members and a single customer representative. These teams normally work in a single open office to promote teamwork and cooperation. The following are few agile methods currently being used in the IT industry.

• Scrum
• Kanban
• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• DSDM
• Essential Unified Process (EssUP)
• Extreme Programming (XP)
• Feature Driven Development (FDD)
• Getting Real
• Open Unified Process (OpenUP)
• Lean Software Development

What is Scrum?

Scrum is an iterative and incremental agile software development framework for managing software projects and product or application development.

• Scrum can be defined as “A small number of people with complementary skills who are committed to a common purpose, performance goals, and approach for which they hold themselves mutually accountable” (Katzenbach and Smith, The Wisdom of Teams)
• Scrum, as a process, is incremental. Each increment is called sprint and each sprint may last for up to four weeks
• In order to work as Scrum suggests, the entire team must possess solid knowledge in analysis design, implementation, testing and documentation.
• Prior to the sprint, there is a sprint planning meeting where the user determines what features should be developed and followed in the next sprint.

The following are the major areas of Scrum

•  Artifacts in Scrum
• Scrum Roles
• Scrum Meetings

The next section is dedicated to providing more details on each of these areas.
Please note that in this document, the focus is to introduce the audience to the basic terms and definitions only.  Please refer to the ‘reference’ section below for further details.

Artifacts in Scrum

In Scrum, there are many artifacts produced and used by the team.  However, the following three artifacts play a key role in overall communication and definition of the requirements and understanding.

• Product Backlog
• Sprint Backlog
• Burn down Chart

Product Backlog

The product backlog is a prioritized features list, containing short descriptions of all functionality desired in the product. Typically, a Scrum team and its product owner begin by writing down everything they can easily think of. This is almost always more than enough for a first sprint. The Scrum product backlog is then allowed to grow and change as more is learned about the product and its customers.

• List of task that needs to be done
• Requirements are defined in the form of user stories.
• The product owner sets the Priority and Business Value for each user story.
• Priority means how “important & urgent” a feature is for the business users and how other features are depending on it
• “Business Value” means the overall impact of the completed feature on the business process.
• Anyone can contribute
• Maintained and posted visibly
• An example would be, "As a shopper, I can review the items in my shopping cart before checking out so that I can see what I've already selected."

A typical product backlog comprises the following different types of items:

• Features
• Bugs
• Technical work
• Knowledge acquisition

Please note that there might be some other item types which can be included in this list. However this is sufficient to start. Feel free to add more as needed.

Sprint Backlog

The sprint backlog is the list of tasks identified by the Scrum Team during sprint planning. During sprint planning, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete.

• List of highest priority task from the product backlog
• Tasks are estimated in hours, usually 1-16
• Task with more than 16 hours are broken down later
• Estimated work remaining is updated daily
• If the work is unclear, define a Sprint Backlog with a larger amount of time, then break it down later
• Update work remaining as more is known and as items are worked

Burn Down Chart

On a Scrum project, the team tracks its progress against a release plan by updating a release burn down chart at the end of each sprint.

• Work remaining on each task is reported during the Daily Scrum meeting, and updated by the Scrum Master
• Notice that this is different than measuring how many hours have been spent on a task
• Time reporting is not a part of Scrum
• Scrum is results oriented, not effort driven. The team reports how time is needed to complete the task rather than how much has been spent.

Scrum Roles

Scrum suggests three main roles for the execution of a successful project.

• Product Owner – When working with Scrum, the product owner is typically a project's key stakeholder. It is important that this person has a vision of what they wish to build and that he or she is able to convey that vision to the Scrum team.
• Scrum Master – The Scrum Master is responsible for making sure a Scrum team lives by the values and practices of Scrum. The Scrum Master is often considered a coach for the team, helping the team do the best work it possibly can. The Scrum Master can also be thought of as a process owner for the team, creating a balance with the project's key stakeholder, who is referred to as the Product Owner.
• Team – A Scrum team does not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to accomplish the work they have collectively committed to complete within a sprint.

The following diagram describes each of these roles along with their respective responsibilities and functions.