The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.
The Development team at Scrum has between 3 and 9 developers in total. The Scrum Master and Product Owner roles are not included.
- Reasons for limiting the Development Team
- Development Team and its physical location
- The Development Team in Scrum is self-organized and cross-functional
- Cross-functionality
- Responsibilities of the Development Team
- Estimating the development time required to complete a User Story
- Supporting the Scrum Process
- Pair programming
If the team has one Scrum Master, one Product Owner, and a Development team of three, the entire Scrum Team is made up of 5 participants in total.
If the Scrum Master and the Product Owner are not part of the Development Team, then the entire Scrum Team will be 11 people total.
If the Scrum Master and the Product Owner take two roles and they are also developers, then the entire Scrum team will be 9 people.
Reasons for limiting the Development Team
The reason behind the suggested limit is that fewer participants will make it challenging to develop a product, and any more would create difficulties complying with the rules and principles of Scrum.
Development Team and its physical location
The main idea for small teams is to achieve self-organization and quick communication in the workplace.
However, these desired effects cannot be guaranteed. The Scrum Master role, as well as the entire Scrum team, must strive for speed and efficiency.
Globally, many organizations use remote teams and Scrum practices at the same time. This can diminish the effectiveness of communication and interaction between teams.
The Development Team in Scrum is self-organized and cross-functional
The main features of the Scrum Development team are self-organization and cross-functionality.
Self-organization
What does self-organization mean when talking about the team? It means that Scrum represents the idea that every member of the team should be active and make their own decisions instead of waiting for orders from management roles.
Scrum does not by itself provide clear instructions about self-organization, but it can be expressed in individual decisions as well as group ones. Time optimization, self-monitoring, workflows, and many other topics can all be taken into account.
Trust among team members is another factor that can increase the productivity of a team.
Competence is another important factor. If a team member has difficulty, then he or she should try to acquire additional skills, or work together with the team to do so.
The Scrum Master role has a significant influence on the self-organization of the team. Guidance, encouragement, and giving attention to all these topics may be required to keep the team focused on their goals.
Indications for a self-organizing Development Team
The main indications that a team can be defined as self-organizing can be the following:
- The team does not have a specific person who makes decisions for everyone or orders others.
- The whole team takes responsibility for the work that is done.
- The team and its members choose their tasks themselves, without anyone else assigning them.
- There should be no situation where Scrum Master, Product Owner, or some team leader assigns tasks.
- All decisions and all teamwork are focused on achieving the Sprint goal.
- The entire team and all members estimate the time required to develop tasks.
- The team provides the work itself.
- The whole team keeps track of their progress and tries to go according to plan.
- The team inspects its work and makes the necessary improvements.
Cross-functionality
Cross-functionality means that all team members and all their general skills are entirely sufficient for the development of the whole product without the need for severe external intervention.
For example, if the product being developed is a mobile application, then at a minimum the Development team should probably include the following specialists:
- Developer, Mobile Technology (Mobile Development)
- User Interface Designer (UI Design)
- Quality Control Specialist (QA)
- System Support and Development Operations Specialist (DevOps)
In such a composition, the team probably can produce the product.
If the Development team consists of the minimum eligible Scrum participants - 3 participants - then they appear to be insufficient for the development of the product.
If the complete skill set of the team is less than the total skills and qualifications required to create the product, the most common practice and the most logical step would be to form a team of professionals who have more than one professional skill.
To develop a mobile application with a team of three participants, if four areas of qualification are required, one team member must have more than one qualification.
The Mobile Developer from the example above may have competencies to handle tasks such as servicing App Store operations, server setup, Cloud Spaces, or anything else that may need to be completed in order to deliver a fully operational mobile application, downloadable and installable.
Another option might be if the designer, for example, has all the skills and competence to handle all the QA work.
Responsibilities of the Development Team
- Creates the so-called Product Increment - product update and enhancement.
- Shares responsibility for creating a quality product, along with the Product Owner role.
- Shares estimated time to complete their tasks.
- Follows all Scrum rules and principles.
The entire Scrum team spends its time working on the Product Increment and working on the planned User Stories until each User Story is ready and evaluated (for example, with Ready status).
Resolving problems
When a member of the team is experiencing difficulties, or there is some obstacle to his/her work, he/she must notify the Scrum Master role.
The Scrum Master role should try to resolve the problem of the team member as quickly as possible.
If a person outside the team interferes with the work of a team member, for example, by contacting them or preventing them from performing their duties, the Scrum Master should be involved in the situation.
All members of the Development Team should try to remove their obstacles on their own, as they must develop skills in organizing and solving problems.
The Development Team needs to be protected
The Scrum Master role protects the team from outside interference like distracting and disturbing factors.
If a member of another team or a business stakeholder wants something, the Scrum Master role must be involved and act appropriately and reasonably. If the situation is fragile, the Scrum Master role offers assistance and explains that they will look into the case, and that the team should remain focused on their responsibilities.
If external intervention involves a work request that needs to be done, the Scrum Master role seeks assistance from the Product Owner role who needs to take action. The Product Owner will, at its discretion, decide to add or ignore this request for new development to the Product Backlog list.
The Development Team must be united
Sharing product quality responsibility may not simply mean that the Development team adheres to the requirements and specifications of their tasks. The Development Team must be united in its practice, its processes, and in finding the right development tools and tests. A certain dose of product care would be a perfect addition to the quality of the product.
It is appropriate for the Development team to choose their working technologies and tools without outsiders requiring specific ones. This freedom of choice allows the Development Team to pick tools and technologies that can achieve better results than those imposed by outsiders.
The Development team is most knowledgeable about technology and expertise
The Development team is most knowledgeable about their skills, technology, level of competence. The team is used to specific tools. When it uses resources with which it has previous experience, the confidence of everyone is greater. Confidence can be a factor in increasing the overall quality of the product and reducing possible errors and defects.
The Development team is welcome to refuse work
The Development team is welcome to refuse to work on a particular User Story during a Sprint if some of the team members are convinced that there is something wrong with the specific User Story. In this case, the team members should discuss their concerns with the Product Owner role.
Possible irregularities in a planned User Story could be, for example, unclear or incomplete requirements, fulfillment failure, or any other aspects that would harm the product as a whole.
In this case, the Product Owner role must accept these comments, understand them, and take the necessary steps to improve or change the planned work (the User Story).
Estimating the development time required to complete a User Story
One essential part of the Development Team’s work is to determine the estimated development time of the User Stories planned for a Sprint. This defines the amount of work they can do for an iteration (Sprint).
The team anticipates the necessary effort to fully complete the work required based on their experience, knowledge, practice, skills, as well as previously done work in the last Sprint.
Relative time
There are two types of development time estimations. The first one is the accurate time to complete tasks — for example, one day or 4 hours. However, Agile practices recommend the use of relative values. The Development Team suggests time only as a guideline, not with accuracy. It is assumed that when estimating the required time for tasks, team members still have no idea how exactly they will perform their work and may lack specific details.
The fixed and always equal length of the Sprint provides the Development team with a measure of their finished work. Also, for future Sprints, estimating the amount of work becomes easier.
Supporting the Scrum Process
Each team member has the responsibility to follow and respect the Scrum process and to ensure that the other members of the team do the same. This is a core responsibility of the Scrum Мaster role, but the entire Scrum team should also support Scrum practices to some extent.
Everyone participating in Scrum events does not miss them or ignore them and is aware of their importance.
Development team members always have an idea of what other team members are doing. The development team maintains the highest level of transparency and does not hide problems.
The technical knowledge and specifics of working on the product are shared with everyone. In this way, if a member leaves the team, the loss will be easier to recover.
Pair programming
Pair programming is another practice that is sometimes used by Agile teams when working on a technology or software product. Generally speaking, it is programming work, or any other kind of technical work, in which a senior and a beginner team member work together on a single task, from one computer, or another work tool.
Pair programming makes it easier for beginners to get into the matter quickly and easily, and everyone has shared knowledge of specific technical topics.
The following issues related to chapter "The Development Team" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of February 25, 2021, 5:04 pm
ID | Issue | Time | Category |
---|---|---|---|
0 | Estimating the development time required to complete a User Story | 60 sec | SM, PO |
1 | The Development Team must be united | 60 sec | SM, PO |
2 | The Development Team in Scrum is self-organized and cross-functional | 60 sec | SM, PO |
3 | Development Team and its physical location | 60 sec | SM, PO |
4 | Responsibilities of the Development Team | 60 sec | SM, PO |
5 | Cross-functionality | 60 sec | SM, PO |
6 | Relative time | 60 sec | SM, PO |
7 | The Development team is most knowledgeable about technology and expertise | 60 sec | SM, PO |
8 | Indications for a self-organizing Development Team | 60 sec | SM, PO |
9 | The Development team is welcome to refuse work | 60 sec | SM, PO |
10 | Self-organization | 60 sec | SM, PO |
11 | Pair programming | 60 sec | SM, PO |
12 | Supporting the Scrum Process | 60 sec | SM, PO |
13 | The Development Team needs to be protected | 60 sec | SM, PO |
14 | Resolving problems | 60 sec | SM, PO |
15 | Reasons for limiting the Development Team | 60 sec | SM, PO |
- Previous article The Product Owner role
Gregory J, Cooper