In Scrum Development, the team is the most important part of the overall Scrum team. Developers create the product.
I present to you several interesting situations concerning specifically the Scrum Development team.
Table of Contents
Can we have large Development teams?
The variant for organizing the teams to work on this project, in this case, would be 3 teams of 6 people, of which the PO and Scrum Master are the same in each. Reference: “Responsibilities of the Scrum Development Team”, https://bvop.org/learnagile/development-team/ [bvop.org] Thus, there will need to be 14 members in total (if 15 are available)
4 specialization team members
– Developer
– UI design or UX design
– QA
– Specialist system support and operations (DevOps)
+
1 pc. RO
1 pc.SM
= 6 pcs. A team of people (if required, max. 10 pcs.)
Do we need a Product Owner on the team?
The Product Owner is an important member of the Scrum Team. They are responsible for overseeing the Product Backlog and ensuring it keeps up with progress in terms of prioritization and aligns with the product vision.
Regardless of the product, the Product Owner is an integral function of the Scrum Team. No role in the Scum team can replace him.
If there are fewer priority products, then they should be completed by another methodology if they do not need a Product Owner, not with Scrum methodology.
Who is the boss of the Scrum team?
In Scrum, there is no boss and all team members self-organize their work.
Requesting reports in Agile is not part of ceremonies. Rather, daily meetings where everyone discusses what has been done, how to proceed, and what obstacles there are in the work.
Do we need project managers in Scrum Development teams?
With this proposal, the director can safely be offered to save his budget for the project manager, because these responsibilities are taken by the Product Owner anyway. All customer requests that arise can be turned into User Stories and discussed in Sprint Planning and the Scrum Team can decide together how to complete them. More on the topic: “Tips for the Scrum Master to deal more easily with the Development team in Scrum“, https://www.islandjournal.net/tips-for-the-scrum-master-to-deal-more-easily-with-the-development-team-in-scrum/
Can a senior developer be the team leader of the Scrum Development team?
Senior programmers to be a lead, manager, strategist, or other. of the team is not characteristic of Scrum practices. A senior developer may work closely with and mentor a junior developer. In Scrum, members should be Cross-Functional. Everyone on the team is equal, and giving more power to a senior developer would go against Scrum’s values.
Can a new entry-level member of the Scrum Development team not interfere in team decisions?
Any member of the team, whether junior or senior, can take part and take responsibility for the work of the product. The caution or reluctance of even one team member to do so would affect the successful work of the entire Scrum Team.
On the contrary, it is even encouraged to take part and take responsibility. Let us recall the Scrum values in this connection:
Dedication, Focus, Openness, Respect, and Courage.
Can Scrum Development team members work remotely?
Neither the Scrum Guide nor the Agile Manifesto prohibits remote work. Face-to-face conversations are the most effective and efficient, but there are situations when working from home is almost the only option.
Distributed scrum teams are teams that are partially or fully remote, adapting to scrum practices for remote work. While scrum provides a framework that can already be useful for remote workers, it is important to adjust some practices and use the right tools for the team to be successful.
What happens if a member of the Development team works overtime individually?
In general, overtime is not encouraged in Scum. The strength of Scrum is in well-planned and organized and transparent teamwork. If any of the team members are overwhelmed by overtime or working on a piece of code or otherwise. at its discretion, then delays, a decline in the quality of work, or even chaos may occur.
But since the framework implies flexibility and if the particular specialist has managed to complete part of the product at once, he can test and be ready for delivery or deployment (be an increment). So in the next sprint, he can discuss with the rest of the team whether he can pull-not “X” no. stories and with the work to achieve the highest added value.
Should the Scrum Master set an estimated time for the team’s tasks?
This proposal, no matter how good it sounds at first glance, would take effort from the Development team to make it work and not just from 1 member of the Scrum team. Reference: “What is the Scrum Master role in the Scrum framework?”, https://pgov.org/what-is-the-scrum-master-role-in-the-scrum-framework/
Planning the work in the sprint to be done is planned jointly by the Scrum team. The daily Scrum meeting is a 15-minute event for the Scrum team to synchronize activities and create a plan for that day.
The Development team defines the Sprint Backlog. So, the PO represents the goals that Sprint should achieve and the tasks from the Backlog that would help achieve those goals. The development team predicts capacity.
Velocity is a measure of the amount of work a team can handle during a sprint, and is the key metric in Scrum. Velocity is calculated at the end of the sprint by summing the points for all fully completed User Stories.
The burndown chart shows the amount of work that was completed in the sprint and the total work remaining. Burndown charts are used to predict the likelihood that the team will complete their work in the available time. They are also great for informing the team about the progress that is happening in the sprint scope.
In conclusion, dev. the team and the Scrum Master should together establish an estimated time to complete the tasks so that the Scrum Master has an effective Burndown chart. This usually takes a few sprites to figure out. Only then can the scrum master plan without the involvement of the dev team. However, constant communication and monitoring are required so that there are no obstacles in the team’s work.
Can Development teams be divided according to the same professions?
Here we have to ask whether the teams have the autonomy to reorganize in the specific case. It should be evaluated with the project managers exactly what approach each parallel product requires.
If they can be approached differently, with the aim of optimal efforts, budget, and results, then:
Agile methodology benefits small teams because it allows them to manage their work more efficiently and effectively. Using an Agile approach, team members can always work on the most important tasks and react quickly to changes in requirements.
The main difference with Waterfall, however, is a linear system of work that requires the team to complete each phase of the project before moving on to the next, while Agile encourages the team to work simultaneously on different phases of the project.
Waterfall also makes it easier to track progress because the scope of the project is known at a moment’s notice. Instead of the entire team prioritizing a stage, the Waterfall methodology involves experts, developers, analysts, and testers focusing on their roles in the project.
What if the User Story does not contain enough information?
User Stories not only describe how the customer will interact with the system, but also provide software developers with a clear description of their short-term program goals. User Stories are critical to the progress of Agile development and must be well written.
The Product Owner is responsible for creating User Stories. Usually, the Product Owner creates them, but sometimes they are developed by the Scrum team in consultation with the Product Owner. Collaboration in the Scrum team is preferred when the Product Owner includes the team in writing User Stories.
Can the Product Owner require team members not to report defects in the product?
The bug is a Product Backlog item. The User Story is another type of Product Backlog item. Bugs and User Stories should be prioritized together in the same Product Backlog and evaluated using the same approach, such as relative estimation.
In any case, covering up or keeping silent about a Bug, be it at the behest of a Product Owner (which is a defamation of Scrum values in itself) is again against the 5 Scrum values: Commitment, Focus, Openness (Openness), Respect and Courage.
The openness in Scrum is the reason why everything like values, rituals, and goals work in product development.
If any of the team decides to keep such events to themselves, it can have a bad impact on the work and the results of the product. Even failure of an entire series of Sprints.
Also fixing defects and bugs on your own is not part of the principles that Scrum follows. The goal of the Scrum team is collaboration and joint problem-solving after assessment and prioritization. Problems, defects, and bugs encountered in development are part of the natural cycle and the SM should help the team deal with such obstacles and agree with the Product Owner on how to prioritize in the next Sprint, etc.
