What are the Agile Scrum Team Roles and what are the core and non-core roles? Who are the Scrum Master, Product owner and Scrum Team?
Agile Scrum Roles
A 59 Seconds Agile Video Animation
The Agile Scrum Team Roles for Developers– Part 2
A 59 Seconds Agile Article
Testers or quality assurance technicians make sure that code is free of bugs. They run through test cases and automate testing where applicable. In many development environments, there is often contention between developers and testers. Developers may see this role as annoying, but it is a vital step in the software development process. Quality assurance seeks to run through every possible scenario, and all of these must perform perfectly.
Roles that take a more hands-off approach to Agile software development are called non-core roles. They rarely have a direct impact on the code, but still, have a connection to the process. These roles still have enough involvement that developers will regularly have to work with them.
As the name implies, stakeholders are anyone who has a stake in the success of a project. Most frequently, this consists of customers and end users. Technically, it also includes core Scrum Team Roles such as the Development team and the Product Owner, but roles with titles are called by their name. Stakeholders benefit when a project does well, and features are released on schedule. Likewise, stakeholders suffer when projects encounter problems and fall behind.
Since developers are part of the Scrum team, they are actually stakeholders themselves. However, unlike other stakeholders, developers have an effect on how the project comes along. Being the ones who write code, developers are directly responsible for making sure features make it into a release when they should. In addition to working for the benefit of other stakeholders, developers also work for their own benefit. However, the users and other stakeholders for a project may need to supply information that developers cannot discern on their own. In this case, the Product Owner acts as a liaison for stakeholders. Stakeholder concerns come through the Product Owner, before reaching developers in a form that is useful.
In software development, organizations will often use existing software and services. There is no reason to re-invent the wheel, especially when other organizations specialize in creating these pieces. Instead of wasting time and resources to create an entire project from scratch, an organization may work with other companies to use components and build their own software around it. The organizations that supply these auxiliary pieces are called vendors. Vendors can provide a variety of different tools and services, but they all require some interface with the Scrum team.
Since vendors can supply such important pieces of the product, it is vital that the developers are able to communicate with them effectively. Developers must understand how the vendor’s service works, in order to properly use it. Specifically, developers often deal with vendors directly, instead of going through other roles first. Agile Scrum Team Roles with less technical knowledge may not be able to relay the information accurately. Developers may use email helplines or other methods to contact vendor representatives and inquire for the information they need.
Scrum Guidance Body
The Scrum Guidance Body is a team in the organization that makes sure the scrum team operates according to Agile principles. While not an enforcing body like federal organizations, the SGB helps out scrum teams that need direction. They are experts in Agile software development and can assist the company in applying Agile.
If an individual Scrum team is uncertain about how Agile may fit for their own case, they contact the SGB. For developers, this means making sure the development environment is organized in an Agile format. If an organization is using Agile principles but development follows waterfall methods, the project will not be ideal.
Agile software development includes a number of different Scrum Team Roles, and every one of these roles has a direct effect on developers. As the main source of code, developers must understand what these roles do, and how they affect the software development process.
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.
The Agile Scrum Team Roles
A 59 Seconds Agile Infographic
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum: