According to the Scrum methodology, the full scope of work is divided into short sprints. Typically, a sprint lasts 2 weeks. Depending on the specifics of your business and products, you might want your sprints to last from 1 to 4 weeks. As soon as a sprint ends, you analyze its results, correct your mistakes and go on working in iterative cycles until you reach one of the following goals:
● Meet the deadline
● Deplete the budget
● Complete enough work items
Scrum teams are cross-functional, flexible and characterized by greater responsiveness to customers. During sprints, they visualize their workflows with the help of charts and boards that allow them to measure their efficiency on the go. Scrum is not a linear process, but rather, a fluid practice. Professionals who adopt this methodology need to take many dynamic elements into consideration.
Before Scrum management became commonplace, organizations used to stick to the Waterfall approach. It would fix the full scope of the project upfront. Before your team would start developing the product, you'd need to prepare exhaustive requirements for it, design the documentation and carry out a thorough analysis. The signature drawbacks of the Waterfall approach are:
● Budget overruns
● Delays
● Inability to prioritize tasks
● Substandard product quality
● Excessive product features that users hardly need
Scrum allows you to avoid these shortcomings because it:
● Breaks down all the work into easily manageable chunks
● Facilitates the process of prioritizing tasks
● Fosters communication and collaboration within your team and between you and your clients
After you switch to Scrum management, you'll be delivering more frequently. You'll be receiving regular feedback from your clients and will be adjusting your workflows and products according to your customers' comments. That will increase your overall business value and clients will be happier with you.
Professionals who work along the Scrum methodology need to perform the following six types of activities:
● Organizing the backlog. This process is also known as "backlog grooming". The backlog is a list of the tasks to complete during the sprint. The person who is in charge of it is known as the "product owner". They constantly stay in touch with the client and monitor the market. Their ultimate goal is to ensure that the ready-to-use product complies with the initial product vision. The product owner receives and processes feedback both from the developers and clients. They prioritize tasks, making sure there are no delays or misinterpretations.
● Plan sprints. Before a sprint begins, the Scrum master organizes a meeting of the entire development team. Altogether, these professionals determine the goal of the upcoming sprint and add relevant user stories from the product backlog. These stories should align with the goal and the developers should have enough resources to implement them during the sprint. By the end of the meeting, every staffer involved should clearly understand what and how they need to deliver during the sprint.
● Sprint. The more complex the work and the more unknowns, the shorter the sprint should be. If your team members realize that they can't cope with the necessary scope of work, they should inform the management about it. The developers should discuss the situation with the product owner to set more realistic goals and deadlines. However, you shouldn't change the duration of the sprint. If it's two weeks, you shouldn't make it longer or shorter. Consistency will allow you to learn from past experiences and apply that insight to future sprints.
● Daily scrum or standup. Every morning, your team should meet for approximately 15 minutes to make sure everyone shares an identical vision of what needs to be done today. The term "standup" means that you don't even need to take a seat. To prepare for this event, each team member should ask themselves the following questions: "What did I do yesterday? What am I planning to do today? Are there any obstacles?". At this meeting, team members can ask questions about today's work and inform others about any concerns that they might have.
● Sprint review. At the end of each sprint, you should take a seat with your whole team and stakeholders. It should be an informal meeting. Your clients should inspect the product and share feedback with you. The product owner will decide whether to release the increment or not. The optimal duration of a sprint review depends on the duration of a sprint. For instance, if the sprint lasted one month, its review should take no more than four hours.
● Sprint retrospective. The retrospective doesn't need to take place at the end of the sprint. You can organize it when your team feels ready to discuss the sprint, or certain ceremonies, or tools, or the project, or people and their relationships. You should focus on positive aspects of your work rather than negative ones. Your team should identify the practices and instruments that it can go on using in the next sprints.
Sometimes, you might come across lists of the main Scrum activities that include only four elements: planning, daily meetings, reviews and retrospectives. Backlogs and sprints might be classified as artifacts then.
We've already clarified the meaning of the term "sprint backlog". In Scrum management, you can also rely on a product backlog — this is a list of functionality that needs to be added to the product. The product owner prioritizes the backlog so that developers begin to work on the most important features first.
Plus, you should use burndown charts. They reveal how much work your team members still need to complete by the end of the sprint. This tool allows you to determine at a glance whether you'll be able to meet the deadline or not.
Another helpful tool is user stories. Such a story describes a piece of software, or a feature of the software, from the user's perspective. It allows developers to understand which features a specific type of client wants to find in the product and why. Your team members will be able to improve the product's code to better meet the needs of your target audience.
Finally, we should mention timebox. All sprints within a project have the same fixed duration. A timebox might have a different duration. It's a predetermined period of time where developers strive to complete a certain goal. Just as sprints, timeboxes can't be prolonged. If the team fails to reach the goal on time, the timebox approach stops. This tool helps Scrum companies to analyze progress and reset goals.
Scrum project management involves three main roles:
● Product owner
● Scrum master
● Developers
The product owner is not responsible for the technical development of the product — but they understand the product's business value better than anyone else. They are the most knowledgeable team member. They are in charge of writing user stories and prioritizing them as well as grooming the product backlog. The product owner serves as the middleman between the development team, the stakeholders and the clients.
The Scrum master ensures the team complies with the Scrum methodology. The role of this professional partly overlaps with the responsibilities of a traditional project manager. However, unlike a project manager, a Scrum master doesn't distribute tasks among team members and doesn't provide day-to-day direction to developers. Instead, they're focused on detecting issues that might slow down the team's progress and finding ways of removing them.
An ideal Scrum development team consists of 5-9 members. They design the product, write the code for it, analyze and test the product. The product owner provides the developers with user stories that serve as the basis for technical communication. Scrum teams are self-organized. All their members are collectively responsible for getting the work done.
Altogether, these professionals work to design and manage the product as well as communicate to key stakeholders and team members. Product owners, Scrum masters and developers take part in all the six types of Scrum activities that were listed above.
It would be a mistake to think that you don't need a project manager if you already have a Scrum master in your team. The representatives of the organizations that have recently switched to the Scrum methodology sometimes think that these two roles are interchangeable or at least largely overlap. In fact, these are two different positions.
The role of a project manager is a traditional one. It is typical for organizations that work along with the conventional Waterfall approach. Meanwhile, Scrum suggests a business should disrupt the old-fashioned way of organizing workflows. A project manager acts as the ultimate decision-maker, takes the fall for any failures and ensures the developers meet all the set goals. In this aspect, the role of a project manager is more similar to that of a product owner in Scrum. A Scrum master, by contrast, avoids taking decision actions or providing answers to problems. They act as coaches and facilitators. Project managers, meanwhile, do make decisions and provide solutions.
In the Scrum methodology, the duties of a traditional project manager can be distributed amongst the developers, the product owner and the Scrum master. However, it doesn't mean that all Scrum teams work without project managers. This professional does something that no one else can do: influences the project, the processes and people.
Project managers of organizations that stick to the Waterfall methodology might oppose switching to Agile because they're afraid of losing their jobs. Instead of firing them, managers should train them to help them faster accept the Agile values. After completing the training, project managers should make sure all the other team members comply with the Scrum standards and don't come back to their old working habits. They should remind others that they should keep learning continuously. Scrum fosters ongoing development and improvement.
The very wording of the roles "product team" and "product owner" suggests that these specialists are focused on the product and not the project. A project manager in Scrum should help teams with compliance issues and reporting. Among all the industry standards that developers need to comply with, those related to data security are the most important ones. The project manager can audit the developers to identify and analyze potential risks.
Businesses switch to Scrum management because of the following benefits of this methodology:
● Enhanced transparency and project visibility. Workflows become more transparent thanks to clearly defined roles of team members, routine check-ins and daily meetings. Managers can easily predict potential bottlenecks or misunderstandings and avoid them.
● Accountability across teams. In the Waterfall approach, managers determine which scope of work each team and each professional should complete within a set period of time. In Scrum, teams themselves decide on their workload. Such an approach enables them to set more realistic goals and deadlines. During the working process, professionals can ask questions and voice their opinions freely. Your staff will appreciate improved communication and collaboration opportunities.
● Flexibility. Teams that work along with the Scrum methodology can easily accommodate changes thanks to constant feedback and short iterations. At regular meetings, professionals can discuss their progress and identify opportunities for changes.
● Reduced expenses. Teams that prefer the Waterfall methodology often face the same challenge: once the final version of the product is almost ready, they discover a serious bug in it. To fix this bug, they need to come back to the initial stages of the working process. It might take them too much time and funds to fix the issue. Scrum, by contrast, allows developers to detect bugs much earlier. Once you discover an issue, you can fix it during the next sprint.
On the flip side, Scrum management has a few disadvantages:
● Scalability. Scaling might become a challenge if the goals remain fluid and change is openly encouraged. Stakeholders might want to set new goals for developers in order to expand the product's functionality. Teams need to adjust to new requirements without compromising on quality.
● Challenges related to managing large teams. As we have already said, the optimal size of the Scrum development team varies from 5 to 9 professionals. If your team is larger, it might be tricky to manage it according to Scrum principles.
● Experience and commitment. To work productively, all your team members should know the Scrum principles very well and value them. If certain professionals don't share this ideology or lack technical expertise, the team won't be efficient.
● Expertise of Scrum masters. The quality of the product, client satisfaction and the company's revenue largely depend on this professional. To become a good master, a person needs to get the experience of working in a well-coordinated Scrum team. They should avoid controlling the team and strive to oversee them instead. The Scrum master and the developers need to build mutual trust and establish a perfect rapport.
● Inaccuracies caused by undefined tasks. At each meeting, team members need to accurately define their tasks. If they fail to do so, it might take them too much time to finalize the project and the expenses will skyrocket. Planning will turn into a challenge and developers might need to complete too many sprints.
As you see, the disadvantages of Scrum management are not too numerous and the advantages far outweigh them.
Professionals who stay loyal to the conventional Waterfall methodology often use the terms Scrum, Kanban and Agile interchangeably but that's a mistake. Scrum is an Agile framework while Kanban is a different framework. To make the most of both frameworks, some businesses merge them into one and call their custom-made methodology "Kanplan" or "Scrumban".
Kanban and Scrum share two main features in common:
● Teams split complex tasks into smaller chunks of manageable work
● Professionals visualize their workflows on boards
Yet these two methodologies differ significantly in their ways of achieving goals.
In Scrum, the full scope of work is divided into small iterations, all of which have the same duration. As soon as a sprint is over, the product team will decide which increments to release in the updated version of the product. If the team fails to meet the deadlines for selected tasks, they can move these tasks to the next sprint. In Kanban, the team plans the tasks or the work in progress ahead, before starting a working cycle. Developers don't calculate in advance how much time it will take them to complete these tasks. They will calculate the time they spent on these tasks once they have finalized them.
Compared to Scrum, Kanban is less structured. The work-in-progress limit is probably the only rigid element that this framework has. The rest is open to interpretation. Unlike Scrum, this methodology lacks such components as daily standups, reviews and retrospectives. Besides, Scrum teams need to be cross-functional — this means, they don't need to depend on external members to achieve their goals. The Kanban methodology doesn't require teams to be cross-functional.
In a nutshell, Kanban might be easier to adopt. Switching to Scrum requires a fundamental shift in the thought process and functioning of a development team.
To be able to work along with the Scrum methodology, you should install task management and project management software. Businesses of all sizes and from all industries value Bitrix24 highly. This product is available as a cloud and on-premise solution as well as an app for iOS and Android. You can try its basic functionality for free and then switch to one of the paid plans. The most affordable one costs $39 per month and accommodates 5 users. The priciest one costs $159 per month and accommodates an unlimited number of users.
Bitrix24 enables you to create an unlimited number of tasks and distribute them among your team members. You can create task dependencies as well as subtasks for each task. This software allows you to visualize all your workflows, which is essential for Scrum. You'll be able to detect bottlenecks long before they occur and avoid them by reallocating resources more rationally. If you wish, the software can send you automated notifications about potential issues.
To plan meetings and other events, you can rely on the Bitrix24 calendars. You can make them private or public. If a calendar is private, only those users who have relevant access rights will be able to access it. It will be easy for you to organize events and invite people to them.
Bitrix24 offers excellent collaboration and communication opportunities. Its built-in contact center allows you to stay in touch both with your staff and external contacts (such as stakeholders, contractors or freelancers). You can make audio and video calls as well as send emails and text messages right from this software's dashboard. Your team members can share files and edit them collaboratively.
Bitrix24 seems to be the perfect tool for organizations that have switched to the Scrum methodology.
Hopefully, you found this article informative and now you have a better understanding of the Scrum methodology with its pros and cons. Compared to the conventional Waterfall approach, this concept is much more flexible. All the scope of work will be divided into short sprints (typically, one sprint lasts two weeks). After your business switches to Scrum, you should make sure all your team members stick to this methodology. When properly implemented, this approach to management should help you to make your workflows more transparent, boost the productivity of your development teams, deliver better products and maximize your income.