Making Use of Agile Methodologies: Scrum Sprints

Scrum is a sprint-based project management methodology where the work is completed in short cycles called sprints, and the team meets daily to discuss current tasks and any roadblocks that need clarification. The methodology allows for more effective collaborations among teams working on complex projects.

In particular, Scrum is a set of meetings, tasks, and resources that work together to help teams organize and handle their workload. While other project management methodologies focus on developing an entire product in one iteration from start to finish, Scrum emphasizes delivering several iterations of a product to provide product owners with the highest business value in the least amount of time. Each iteration is divided into two to four-week sprints, with the objective of building the most valuable features first. In subsequent sprints, more features can be added to the product, or the current features can be adjusted based on customer feedback in between sprints.

Benefits of the Scrum Methodology

Scrum is used for fostering successful collaboration among teams working on complex projects. This methodology has many benefits. Since each set of goals must be completed within each sprint’s time frame, Scrum accelerates quicker product development. It also requires frequent planning and goal-setting, which lets development teams focus on the current sprint’s goals and increase efficiency.

Here are some of the benefits of scrum methodology:

Scrum’s biggest advantage is its flexibility. In conventional project management frameworks, product owners don’t get regular feedback, and time is wasted on trying to adjust the product halfway through development – or, worse still, the team has to start again after the product has been created.

In contrast to traditional methodologies, a scrum team usually receives feedback from the client after each sprint. If any issues arise, the team can quickly alter product features or goals in future sprints to provide more efficient iterations. In this scenario, clients are happier because they get exactly what they want and are involved at every level.

When to Use Scrum

Scrum is a good fit for long-term, complex projects that require feedback from product owners, which can have a significant impact on project requirements. Scrum could be the best choice when the exact amount of work can’t be estimated and the release date isn’t set.

Scrum has earned the trust of 89% of Agile users because it prioritizes customer needs and sets on-time/on-budget delivery. Thus, there’s a growing number of companies adopting this methodology, including Microsoft, IBM, Yahoo, and Google.

According to the Scrum Alliance’s report, Scrum has applications beyond IT. This methodology is used by companies in the fields of banking, fintech education, retail, media, and entertainment to organize their workflow and improve interaction with customers.

How We Are Organizing Scrum

In Scrum, we typically work in sprints depending on the extent of the overall project. First of all, we prepare a Product Backlog based on a prioritized list of tasks (User Story) to be fulfilled. The prioritizing criterion is Business Value that is the anticipated profit caused by task execution.

The next stage is the Estimation of each task performed directly by the developers who simultaneously find out other details required for this task execution. Estimation may influence task prioritizing made by the customer and this may cause re-arrangement of tasks according to new priorities.

After that, we define Sprint terms, select tasks from the Product Backlog (in the top-down direction) and sum up their Estimation. Then we transfer those tasks into a document called Sprint Backlog (a list of items to be completed during the current sprint, taken from the product backlog) until the Estimation total is lower than the number of tasks that the team can execute during the iteration. Our Sprint duration is 2 to 4 weeks, which is normally applied in practice.

Every morning, in the course of the current Sprint the team carries out a Standup Meeting to actualize Sprint Backlog, reveal and discuss the related problems. The Sprint being over, the team provides the customer with a stable release version of the application.

Prior to a new iteration, the team analyzes the results of the previous Sprint and makes organizational corrections in the development process to adjust it for the current project. To prepare a new Sprint we delete the fulfilled tasks from the Product Backlog, add new tasks, adjust tasks priorities and Estimations, appoint terms and compose a User Story. After that, the team continues its work within the framework of a new iteration.

Using Sprints has proven highly efficient. According to the statistics we have accumulated, it allows to achieve the following results upon average:

Scrum works well when the key goals are clearly determined and the work scope is specified within one to four weeks. This way, we make sure that the software stays relevant up to the end of the sprint.

We employ all of the traditional methodology pillars, including estimation, sprints lasting one to four weeks, daily meetings, sprint review demonstrations, retrospectives, and task backlog management.

The length of sprints may vary. We always start with one week to shape the new team’s coefficients. Sprint’s effectiveness is not always ideal at the start but it improves by the third or subsequent Sprints. The major reasons are that new team members need time to get to know each other, and productivity coefficients of each teammate are not always set up correctly from the start.

Here is what we have learned from our experience of using Scrum:  while certain changes in Scrum are possible, it is best to remain as close to the Scrum requirements as possible. Our experience has taught us what to do and what to avoid, how to calculate the cost of arising issues.

Examples

• When there are multiple product owners, the point of truth starts to blur. When dealing with a business, there should only be one point of truth; otherwise, ambiguity will hit when you least expect it.
• When a development team grows to more than seven people, it gets slow. When a team reaches its capacity limit, it should be reorganized into smaller groups.
• If the retrospective is not performed, mistakes go unnoticed, and the team wastes time by repeating them. Sprints will always be broken.
• If the feature size isn’t estimated correctly, it’s defined as a Story (rather than an Epic), and the team can’t complete it in one Sprint, the team will be faced with turmoil as uncontrolled features bounce from one planned week to the next, causing the roadmap to be ruined.

Sprint Planning Best Practices

It’s easy to get caught up in the details of sprint planning and forget that the goal is to create a “just enough” plan for the next sprint. The plan shouldn’t be a detailed instruction for every single step, instead, it should help the team focus on important outcomes and put some guardrails in place for self-organization. A successful sprint plan fires team members with enthusiasm by describing an outcome and a strategy for achieving it. However, don’t plan too far ahead of time. Instead of creating the most comprehensive sprint plan with a detailed timeline, focus on the objectives and create enough of a sprint backlog to get started. Next, make sure the product backlog is organized so that the team can start working on it.

Scrum is a methodology for resolving complex problems. Complex issues necessarily require an empirical approach – learning by doing. Empirical processes are extremely difficult to plan, so don’t fool yourself: you can’t create the perfect plan. Instead, concentrate on the results and get started.