- Services
Development Services
Development Services
- Hire Developers
- Solutions
- How We Work
Build and Delivery
Build and Delivery
- Company
- Contact Us
In the agile Scrum world, instead of providing complete, detailed descriptions of how everything is to be done on a project, much of it is left up to the Scrum software development team. This is because the team will know best how to solve the problem they are presented.
This is why in Scrum development, for example, a sprint planning meeting is described in terms of the desired outcome (a commitment to a set of features to be developed in the next sprint) instead of a set of Entry criteria, Task definitions, Validation criteria, Exit criteria (ETVX) and so on, as would be provided in most methodologies.
Scrum relies on a self-organizing, cross-functional team. The scrum team is self-organizing in that there is no overall team leader who decides which person will do which task or how a problem will be solved. Those are issues that are decided by the team as a whole.
And in Scrum, a team is cross functional, meaning everyone is needed to take a feature from idea to implementation.
Within agile development, Scrum teams are supported by two specific roles. The first is a ScrumMaster, who can be thought of as a coach for the team, helping team members use the Scrum process to perform at the highest level.
The product owner (PO) is the other role, and in Scrum software development, represents the business, customers, or users, and guides the team toward building the right product.
At its core, Scrum is an iterative approach to software development. Scrum splits a large project into many time intervals known as sprints. Sprints generally last between one week and one month, averaging about 14 days. During each sprint, developers focus on a particular set of features, making the idea become reality through careful coding and testing.
Each sprint can be subdivided into smaller activities. Each sprint kicks off with a sprint planning meeting during which the team members identify the top priorities and list the ones that they can realistically perform in the product backlog.
Throughout the sprint, there are daily meetings that are capped at 15 minutes. Team members share information about their progress the previous day, their plans for the current day, and any potential obstacles. These meetings align the team members’ efforts and keep everyone’s work on track.
As the sprint draws to an end, the sprint review allows the team to demonstrate its accomplishments. The product owner and/or users are invited to view the new functionality and provide detailed feedback, which is then incorporated into the next product backlog.
The sprint retrospective occurs at approximately the same time. This is an opportunity for all the team members to discuss the process itself, sharing their thoughts about the concluding sprint and any ideas for making the next sprint more productive and more successful.
The Scrum product owner is typically a project's key stakeholder. Part of the product owner's responsibilities is to have a vision of what he or she wishes to build, and convey that vision to the scrum team. This is key to successfully starting any agile software development project. The agile product owner does this 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 marketplace, the competition, and of future trends for the domain or type of system being developed.
The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.
The responsibilities of this role include:
The scrum master role was created as part of the Scrum framework. The name was initially intended to indicate someone who is an expert at Scrum and can therefore coach others.
The role does not generally have any actual authority. People filling this role have to lead from a position of influence, often taking a servant-leadership stance.
Scrum Teams are small. The ideal size is 7 +/- 2 people.
If there are more people the communication overhead gets too large and the team should be split into multiple Scrum Teams. These Scrum Teams should be coordinated and communicate with each other but otherwise work independently.
To minimize unnecessary communication overhead each Scrum Team should be collocated. If work has to be spread over multiple locations, independent Scrum Teams should be created.