SCRUM ROLE : THE SCRUM TEAM

Scrum teams do not include any of the traditional software engineering roles such as programmer, designer, tester, or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together".

A typical Scrum team is 5-9 people. Rather than scaling by having a large team, Scrum projects scale through having teams of teams. 

Although not the only thing necessary to scale Scrum, one well-known technique is the use of a "Scrum of Scrums" meeting. With this approach each Scrum team proceeds as normal but each team identifies one person who attends Scrum of Scrum meetings to coordinate the work of multiple Scrum teams. These meetings are analogous to the Daily Scrum Meeting, but do not necessarily happen every day. In many organizations, having a Scrum of Scrums meeting two or three times a week is sufficient.

SCRUM ROLE : SCRUM MASTER

The ScrumMaster is responsible for making sure a Scrum team lives by the values and practices of Scrum. The ScrumMaster is often considered a coach for the team, helping the team do the best work it possibly can. The ScrumMaster 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.

The ScrumMaster does anything possible to help the team perform at their highest level. This involves removing any impediments to progress, facilitating meetings, and doing things like working with the product owner to make sure the product backlog is in good shape and ready for the next sprint. The ScrumMaster role is commonly filled by a former project manager or a technical team leader but can be anyone.

The ScrumMaster is also often viewed as a protector of the team. The most common example is that the ScrumMaster protects the team by making sure they do not over-commit themselves to what they can achieve during a sprint due to pressure from an overly aggressive product owner. However, a good ScrumMaster also protects the team from complacency.

Many who are new to the ScrumMaster role struggle with the apparent contradiction of the ScrumMaster as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the ScrumMaster has no authority over Scrum team members, the ScrumMaster does have authority over the process. Although a ScrumMaster may not be able to say, “You’re fired,” a ScrumMaster can say, “I’ve decided we’re going to try two-week sprints for the next month.”

The ScrumMaster is there to help the team in its use of Scrum. Think of the help from a ScrumMaster as similar to a personal trainer who helps you stick with an exercise regimen and perform all exercises with the correct form. A good trainer will provide motivation while at the same time making sure you don’t cheat by skipping a hard exercise. The trainer’s authority, however, is limited. The trainer cannot make you do an exercise you don’t want to do. Instead, the trainer reminds you of your goals and how you’ve chosen to meet them. To the extent that the trainer does have authority, it has been granted by the client. ScrumMasters are much the same: They have authority, but that authority is granted to them by the team.

A ScrumMaster can say to a team, “Look, we’re supposed to deliver potentially shippable software at the end of each sprint. We didn’t do that this time. What can we do to make sure we do better the next sprint?” This is the Scrum- Master exerting authority over the process; something has gone wrong with the process if the team has failed to deliver something potentially shippable. But because the ScrumMaster’s authority does not extend beyond the process, the same ScrumMaster should not say, “Because we failed to deliver something potentially shippable the last sprint, I want Tod to review all code before it gets checked in.” Having Tod review the code might be a good idea, but the decision is not the ScrumMaster’s to make. Doing so goes beyond authority over the process and enters into how the team works.

Scrum Role : 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. This is key to successfully beginning any agile software development project. Product owner's do this through in part through the product backlog, which is a prioritized features list for the product.

The product owner is commonly a lead user of the system or someone from marketing, product management, or anyone with a solid understanding of users, the market place, the competition, and of future trends for the domain or type of system being developed. This of course varies tremendously based on whether the team is developing commercial software, software for internal use, hardware, or some other type of product. The key is the person in this role needs to have a vision for what is to be built.

Although the product owner prioritizes the product backlog, during the sprint planning meeting the team selects the amount of work they believe they can do during each sprint and how many sprints will be required. The product owner does not get to say, "We have four sprints left, therefore you must do one-fourth of the product backlog this sprint." The product owner's job is to motivate the team with a clear, elevating goal. Team members know best what they are capable of and so they select which user stories from the top of the product backlog they can commit to delivering during any sprint.

In return for the scrum team's commitment to completing the selected user stories from the top of the product backlog, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint. Once the team starts on a sprint it remains maniacally focused on the goal of that sprint.

An Overview of Scrum for Agile Software Development

As a brief introduction, Scrum is an agile process most commonly used for product development, especially software development. Scrum is, however, a general-purpose project management framework that is applicable to any project with aggressive deadlines with complex requirements and a degree of uniqueness. In Scrum, projects progress via a series of iterations called sprints. Each sprint is typically 2-4 weeks long.

• Scrum has three roles product owner, Scrum Master and The Team Members.
• Scrum uses three artefacts Product backlog, Sprint Backlogs and Burn down Chart to guide the team during the sprint.
• The product owner takes care of the Product Backlogs. The Backlog is the list of the every desirable outcome user expect from the product. This is the centrally TO DO LIST of GOAL.
• Scrum defines three ceremonies Sprint Planning, Daily Scrum and Sprint Review & Retrospective.
• The Scrum Master is the facility there for the team. He helps the team members to follow the ceremonies and effectively use the artefacts. 

SCRUM OVERVIEW - INTRODUCTION TO SCRUM TERMS:

An introduction to Scrum would not be complete without giving details on all the Scrum terms that you will come across. This section of our Scrum overview lists all these terms and gives you some brief details with a link to more detailed information.

A typical scrum team has between five and nine people, but Scrum projects can easily scale into the hundreds. Scrum can easily be used by one-person teams and often is. The 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 complete the set of work they have collectively committed to complete within a sprint. Scrum teams develop a deep form of camaraderie and a feeling that “we’re all in this together.”

The product owner is the project’s key stakeholder and represents users, customers and others in the process. The product owner is often someone from product management or marketing, a key stakeholder or a key user.

The ScrumMaster is responsible for making sure the team is as productive as possible. The ScrumMaster does this by helping the team use the Scrum process, by removing impediments (Obstacles) to progress, by protecting the team from outside, and so on.

The product backlog is a prioritized features list containing every desired feature or change to the product. At the start of each sprint, a sprint planning meeting is held during which the product owner presents the top items on the product backlog to the team, and the Scrum team selects the work they can complete during the coming sprint. That work is then moved from the product backlog to a sprint backlog, which is the list of tasks needed to complete the product backlog items the team has committed to complete in the sprint.

Each day during the sprint, a brief meeting called the daily scrum is conducted. This meeting helps set the context for each day’s work and helps the team stay on track. All team members are required to attend the daily scrum.

At the end of each sprint, the team demonstrates the completed functionality at a sprint review meeting, during which, the team shows what they accomplished during the sprint. Typically, this takes the form of a demonstration of the new features, but in an informal way; for example, PowerPoint slides are not allowed. The meeting must not become a task in itself nor a distraction from the process.

Also at the end of each sprint, the team conducts a sprint retrospective, which is a meeting during which the team (including its ScrumMaster and product owner) reflect on how well Scrum is working for them and what changes they may wish to make for it to work even better.

Note: The term “backlog” can get confusing because it’s used for two different things. To clarify: the product backlog is a list of desired features for the product. The sprint backlog is a list of tasks to be completed in a sprint.

What is Scrum?

What is Scrum?

“Scrum” is agile framework that helps teams deliver customer value early and often in a highly predictable manner.

The Scrum Way:

Scrum Roles:

1. Product Owner
2. Scrum Master
3. The Team

1. Product Owner is responsible for maximizing the business value delivered by the team.

• One person responsible for the backlog and story priority
• Accepts or rejects work
• Helps define “Done”
• Knowledgeable, empowered, engaged.
• Motivates team, celebrates success!

2. Scrum Master is responsible for facilitating the scrum process and ensuring the team is delivering value.

• Helps builds self-organizing teams
• Removes impediments
• Keep the process healthy
• Empowers the team – Servant Leader !!!

3. The Team is responsible for turning the product backlog items into increments of value each sprint.

• Cross Functional team, 7 or +-2
• Self-Organizing, Collaborative
• Committed
• Generalizing Specialists
• Deliver Value in small Chunks
• Focused on Customer, Build in Quality

Agile Scrum

Agile Scrum - An Overview

Many of us have experienced projects that drag on much longer than expected and cost more than planned. Companies looking to improve their software development processes are now exploring how Agile can help their Enterprise more reliably deliver software quickly, iteratively and with a feature set that hits that mark. While Agile has different "flavors", Scrum is one process for implementing Agile. This Article will discuss the Agile Scrum process and will end with variants of Scrum that can be used to aid in improving your software releases.

So what is Agile?

According to Wikipedia, Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration. By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner. This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production. Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.

So what is Scrum?

Scrum is process of implementing Agile, where features are delivered in 30 day sprints. Scrum borrows its name from Rugby, where a sprint is the process of stopping play, then vigorously playing until the sprint ends and a new one begins. The same idea applies here, where you define the requirements for a 30 day sprint and work on them with vigor for 30 days without being sidetracked by other things or having things re-prioritized. A specific feature is not recognized as being completed until it is analyzed, designed, coded, tested, re-factored and documented. At the end of the 30 day sprint, most features defined in the 30-day sprint should be completed. If some did not get finished (because of being underestimated), the uncompleted features can be moved to a later sprint. A sprint is considered successful if all the completed features have high quality and can be put into production (or beta) upon ending the sprint.

By: Mann Bhammar
      Test Analyst

Agile Process in Software Development/Testing

Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. 

The main features of Agile Development are:-

Incremental, Iterative, Adaptive-Agile Development follows a descriptive approach and builds the system gradually. Typically, it has 2 weeks of iterations, which includes requirements development and testing. Thus it has multiple checkpoints during a project.

Regularly delivers business value-Work is broken into stories also known as use-cases and each of them is defined with some acceptance criteria.

Collaborative-Agile Development also members to work in different modules and does not require specialized knowledge.

No Backsliding-Agile development automatically includes unit testing and continuous integration testing in a test driven development method. Also, it leaves little scope of failure as regression testing is also a crucial part of Agile Development.

 Agile in Software Testing:-

Agile methods were developed as a response to the issues that the traditional V-Model and waterfall methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed.

A software tester’s role in traditional software development methodology, a.k.a Waterfall & the V-model can be generally summarised as:

1.       Finding defects in development products, such as requirements and design documents

2.       Proving that the software meets these requirements

3.       Finding where the software under test breaks (whether that is through verification of requirements or validation that it is fit for purpose)

A tester’s life in a V-Model or waterfall based software project world is, for most traditionally trained testers, the basic process they steps they perform are similar to the following:

• They receive a requirements document which they proceed to review
• They eventually get a requirements document that is considered baselined or signed-off
• They analyse these requirements to create test conditions and test cases
• They write their test procedures
• Then they wait for a piece of software to miraculously appear in their test environment.
• They now start executing their tests
• Oh and now they begin re-executing some of these tests as they now start iterating through new builds which are released to fix bugs or they may even include new functionality
• Then they reach the acceptable risk= enough testing point (or the fixed immovable deadline) and the software is released

Now, while all the above sounds logical and “easy” to do, the real world we live in makes it not quite so straight forward! Requirements are never complete and there are always ambiguities to deal with. The worst case is the software meets its specifications but doesn’t meet the user needs.

Wouldn’t it be better to build smaller parts of the system, have the business work with the developers and testers to confirm that what’s being built is indeed what they want and need? So lets build the system in small increments, increasing the systems functionality in each release, and potentially deliver a working system at the end of each increment that actually meets the end users needs?