Currently it is quite difficult to find a company that does not use this method of project management. Since we have quite a lot of advantages, and we are talking not only about the field of software development, but also in other sectors. But let’s look at the agile development in details.
SCRUM is an agile way to manage your projects. You can think about the Agile software development with Scrum as a framework for managing a process: developing, delivering, and sustaining complex products. Designed for teams of nine-ten or fewer participants, who continuously break their work into smaller tasks / goals that can be achieved within certain time-boxed iterations.
The whole process can be represented as follows:
Scrum model suggests that projects progress via a series of sprints. In keeping with an agile methodology, sprints are timeboxed, usually two weeks, but no more than a month long. The main reason is that the modern market demands quality, fast delivery at lower costs, for which a company must be very agile and flexible in the development of products, to achieve short development cycles that can meet the demand of customers without undermining the quality of the result.
Scrum methodology recommends holding a planning meeting session at the start of the sprint (first day of a new sprint), where team members figure out how many tasks they can commit to, and then create a sprint backlog – a list of the selected tasks to perform during the sprint.
The event should occur after the sprint review and retrospective from the previous sprint so that any output from those discussions can be considered when planning for the new sprint. It does not have to occur immediately after those other two events. You’ll find it’s best to place a higher priority on scheduling sprint planning when the entire team is available.
During an agile Scrum sprint, the Scrum team takes a small set of features from idea to coded and tested functionality. At the end, these features are done, meaning coded, tested and integrated into the evolving product or system.
How is Sprint Planning Structured?
Sprint planning is typically split into two parts:
Part 1 – Scope
The team selects which items from a prioritized list of ready product backlog items (usually expressed as user stories) they forecast they will be able to complete during the sprint.
Here’s a sample agenda for the first part of sprint planning:
- What is the goal for this sprint? Use this as a decision filter to determine which product backlog items to include in the sprint.
- What product backlog items are ready and contribute toward the sprint goal?
- Who is available for this sprint? Identify any vacations, holidays, other activities that will impact everyone’s availability during the sprint.
- What is the team’s capacity based on everyone’s availability
- What items will the team include on the sprint backlog based on the sprint goal and the team’s capacity.
- How confident does the team feel that they’ll be able to meet the sprint goal.
Part 2 – Plan
The team discusses in more detail how they will deliver the selected product backlog items. This may (but does not have to) include identifying tasks for the product backlog items, whether there are any dependencies between the items, and signing up for the initial product backlog items that each team member works on.
On each day of the sprint, by mornings, all team members attend a daily standup (or Daily Scrum) meeting, including the ScrumMaster and the product owner. This meeting is timeboxed to no more than 15 minutes. During that time, team members share what they worked on yesterday, plans for today, and identify any blockers to progress. It helps to synchronize the work of team members as they discuss the work of the sprint.
At the end of a sprint, the team conducts a sprint review during which the team demonstrates the new functionality to the PO or any other stakeholder who wishes to provide feedback that could influence the next sprint.
This feedback loop within Scrum software development may result in changes to the freshly delivered functionality, but it may just as likely result in revising or adding items to the product backlog.
Another activity in Scrum project management is the Sprint Retrospective at the end of each sprint. The team reviews the completed goals of the finished sprint, write down the good and the bad, so as not to repeat the mistakes again. This stage serves to implement improvements from the point of view of the development process. The goal of the sprint retrospective is to identify possible process improvements and generate a plan to implement them in the next Sprint.
Roles in Scrum
In Scrum, the team focuses on building quality software. The owner of a Scrum project focuses on defining what are the characteristics that the product must have to build (what to build, what not and in what order) and to overcome any obstacle that could hinder the task of the development team.
The Scrum team consists of the following roles:
Scrum master: The person who leads the team guiding them to comply with the rules and processes of the methodology. Scrum master manages the reduction of impediments of the project and works with the Product Owner to maximize the ROI. The Scrum Master is in charge of keeping Scrum up to date, providing coaching, mentoring and training to the teams in case it needs it.
Product owner (PO): Is the representative of the stakeholders and customers who use the software. They focus on the business part and is responsible for the ROI of the project. They translate the vision of the project to the team, validate the benefits in stories to be incorporated into the Product Backlog and prioritize them on a regular basis.
Team: A group of professionals with the necessary technical knowledge who develop the project jointly carrying out the stories they commit to at the start of each sprint.
Scrum Methodology benefits
Easily Scalable: Scrum processes are iterative and are handled within specific work periods, which make it easier for the team to focus on definite functionalities for each period. This not only has the benefit of achieving better deliverables in line with the needs of the user, but also gives the ability to the teams to scale the modules in terms of functionality, design, scope and characteristics in an orderly, transparent and simple manner.
Compliance of expectations: The client establishes their expectations indicating the value that each requirement/ history of the project brings, the team estimates them and with this information the Product Owner establishes its priority. On a regular basis, in the sprint demos, the Product Owner verifies that the requirements have been met and transmits feedback to the team.
Flexible to changes: Quick reaction to changes in requirements generated by customer needs or market developments. The methodology is designed to adapt to the changing requirements that complex projects entail.
Time to Market reduction: The client can start using the most important functionalities of the project before the product is completely ready.
Higher software quality: The working method and the need to obtain a functional version after each iteration, helps to obtain a higher quality software.
Timely Prediction: Using this methodology, we know the average speed of the team by sprint (story points), with which, consequently, it is possible to estimate when a certain functionality that is still in the backlog will be available.
Reduction of risks: The fact of carrying out the most valuable functionalities in the first place and of knowing the speed with which the team advances in the project, allows to clear risks effectively in advance.
