The word ‘Scrum’ is currently in general use but for an average person fat from IT, a phrase ‘the Scrum software development methodology’ may sound strange and even awkward. A number of books and articles are devoted to the topic of Scrum but as written in a sophisticated technical language, they may occur of little help. If you discovered the world of information technologies and software development not long ago, read this article, where we tried to explain this concept at the elementary level.
To learn more about Scrum, we need to define such a notion as Agile first, which is frequently used together with Scrum. Agile, or Agile software development, is normally determined as a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. In simple words, the Agile methodologies allow members of a development team to coordinate their work and iteratively (at regular intervals) deliver some working functionality of a product, rather than deliver a whole product at once after a long time of development. The Agile methodologies are based on 4 ideas, which are codified in the document known as Agile Manifesto:
1. People and interaction are more important than processes and tools
2. Working software is more important than comprehensive documentation
3. Customer collaboration is more important than contract negotiation
4. Responding to change is more important than following a plan
The most well-known methodologies that Agile includes are Scrum and Kanban. However, the Scrum methodology is considered to be more popular among development teams – a vast majority of projects are developed with the help of this approach. For better understanding let’s try to observe the whole process of software development in the Scrum format.
The process starts with an idea that came to a customer’s mind. In order to put this idea into action, first of all, a customer needs funding and a product owner. A product owner (should not be mixed up with a customer) discusses all requirements to the software with the customer and represents their interests while negotiating with a Business Analyst (or simply BA), whose responsibility is to transfer the customer’s idea into a technical task and development specifications.
On the base of customer’s demands, a BA together with a product owner creates a so-called backlog – a list of tasks for developers to solve. The backlog consists of several epics. An epic is a huge unit of work and is usually divided into several user stories. A user story, in turn, is a requirement for some options of the product. Stories usually have the following format: “As a user, I want to…”. To be noted is that all stories in the backlog are listed in accordance with their priority. The created backlog finally goes to a development team.
A key element of Scrum is a sprint – a time period (usually a couple of weeks) during which a team is supposed to complete a certain number of stories. It normally takes several sprints to develop a software product. A sprint starts with a team meeting which is called a planning poker. At this meeting, user stories are split into subtasks. Then the members of the team estimate the difficulty of each subtask with story points.
After a brief discussion of a task, everyone shares their personal estimate. Such estimates are usually more or less equal but if there is a big difference, everyone explains their choice and then makes estimates again. Also, it is necessary to estimate not only the difficulty of each subtask but also the time needed for their completion. Then, when all subtasks are estimated, they are shared among developers, and the sprint is launched.
The team has a so-called Scrum dashboard with five columns: ‘to do’, ‘rejected’, ‘in progress’, ‘ready for QA’ and ‘done’. At the beginning of the development, all subtasks are placed in the first column ‘to do’. Then, a developer takes one subtask and moves it to the column ‘in progress’. After completing, the subtask goes to the column ‘ready for QA’. A quality assurance engineer tests it and if finds any bugs, moves the subtask to the column ‘rejected’. The developer fixes bugs, then the testing phase again, and in case no bugs are found, the task goes to the column ‘done’. A development team has daily Scrum meetings, where everyone says what they have already done and what they are going to do further. Such meetings help a team to coordinate their work.
A sprint ends with a review meeting to demonstrate the results to the customer and the product owner and to deliver a ready functionality. After the review, another meeting takes place – retrospective. Here the team discusses what they did good, what they failed in, and what aspects should be improved in the future. It is important to estimate the effectiveness of the team – story points of all stories completed during a sprint are summarized, it helps to plan the work of the following sprint. In fact, all these meetings are organized by a Scrum Master who monitors the correct implementation of the Scrum approach and solves possible problems inside the team.
Note that the Scrum methodology is applicable only for small teams of no more than 8-9 people. There is one chuckly rule to define whether your team can use Scrum, this rule is known as ‘the rule of 2 pizzas’. If two pizzas are enough to feed your team, Scrum suits you perfectly. If no, you’d better choose another approach.
The work process in Scrum (as well as any other Agile methodology) is built on continuous communication, which plays a great role in creating great software and satisfying a customer. Another obvious advantage is the possibility to perform certain changes to the project, it is achieved owing also to sprint planning.
To sum up, Agile project management brings true benefits coming down to a high quality of a product, high satisfaction of a customer, better project control and reduced risks. We hope that this article helped you to understand Agile and Scrum and to realize how such a concept can advance the development of your product.