How do we make a scrum and what comes of it

Write Close
Do you have any questions? Contact us!
I agree the Terms of Service
published January 24, 2020

"Democracy is the worst form of government, except for everyone else." Winston Churchill
Churchill did not mean, of course, that it was a bad political system, there simply weren't any uniquely perfect systems, but striving for them was our professional duty. Democracy only sets the direction of movement. The situation with the Scrum methodology is similar.

Scrum, as a flexible project management methodology, is actively used in the
creation of information systems, sites, and software development. This methodology was developed over 20 years ago.
And few people know that the methodology originates in no way in the field of programming, but is a term in a Rugby game. But at the moment, it is in the area of programming that this methodology is most popular.
Scrum is a management framework according to which one or several cross-functional self-organized teams create a product by increments in small iterations (sprint), i.e., in stages.
"SCRUM - is built on a set of principles, values, rallies, roles, policies, rituals, and artifacts. An ambiguous definition, isn't it? Let's talk about how we make Scrum and what we get from this.

For us, the advantage of Scrum is that the methodology does not contain strict instructions, but only sets the direction. This is a very convenient tool that adapts to each specific project and can be upgraded depending on the working conditions of the team or client.

The first installation with which we start the project is complicated for the customer. You need to understand that he cannot prepare a strategic plan for the development of the project and can be frightened that he does not know whether his product will be in demand and relevant on the market. The unknown scares him, especially now, when the length of the route is not yet known, and you need to pay for this way now.

At this stage, it is important to build productive communication with the client. We have to identify all the technical requirements and help the customer draw up the most detailed technical specifications, which the team will then have to work on. We already wrote about how this process goes into one of our articles: this. The technical task will need to be divided into small parts (user story), which can be easily implemented in a reasonably short time (sprint) and allow the customer to "touch" it. We are always ready for the client to change priorities at any time and adjust to the competitive market, and, then, a technical task may change.

After we received the terms of reference and agreed with customers about the working conditions, it is time to move on to the formation of the team.
Scrum-team is a small group that includes customers, product owners, scrum master, and developers. In our case, customers most often act as stakeholders, and the role of the product owner can be performed by a person on the part of the customer or our colleague in the position of a project manager.

Of course, an important part of the team is the developers (our superheroes), who must possess the technology stack and qualifications necessary for this project, as well as communication skills. As a rule, we have a self-organizing team, each member of which can carry out any task, is not afraid to put forward ideas. Because according to the values of Scrum, the voice of each team member is important, and there is no clear hierarchy in it - the boss and subordinates.

By the way, the concept of a project manager in pure Scrum is not, but there is the role of a scrum master. Its task is to help comfortably go the way and get all the team members to the goal. He is a forger, psychologist, trainer, mentor, assistant, change agent, "alarm clock," and a reminder all rolled into one. His task is not to push, not to do all the work himself and not to allocate responsibilities, but to help, guide, and resolve issues that impede the development process.
In a Scrum book, the role of the scrum master is usually played by a separate employee. Our process is primarily modified, and the project manager acts as a scrum-master.
After the team is formed and all the formalities are observed, we can begin to work.

For a comfortable start of work, we devote a lot of time to creating a backlog. Product backlog - a list of requirements, stories, features, Wishlist, functionality, which the product owner arranges by the degree of importance, prioritizing after agreeing with stakeholders. The development team also has its voice in priority tasks on the advice of the team, you can add technical tasks and explain to the product owner why this is important. All team members are closely connected and take part in the discussion. Moreover, all requirements are described in a language that is understandable for business. Elements of this list are user stories, "user stories."
More recently, we began to write custom stories using the Gherkin language. This was the right solution and made it possible to describe the problem in more detail, leaving almost no possibility that the person deciding it could interpret something differently from what was supposed, and the stakeholder saw all the scenarios. By describing stories in this way, we can be sure that the developer implements everything correctly according to the script, and the QA tester can readily verify everything. It is also very important to describe the acceptance criteria, and then it immediately becomes clear what to consider as a completed task and by what criteria.
Writing a user story is not difficult. Here is an example: I was a burger absorber. I want to get a paper-wrapped burger of three components so as not to get your hands dirty.
Acceptance Criteria:
1. I have a hamburger with meat, bun, and cheese
2. Hamburger wrapped in paper

The next important step in work is sprint planning.
Sprint is a period of time, after which the customer receives a very useful, albeit small, but functional. He has time to test it in action, pass it on to the consumer, and receive feedback based on which we can adjust further work on the product.

Usually, our sprints last two weeks. Short sprints are comfortable. They allow the team to be as "flexible" as possible: ready to often adjust their plans. A short sprint means a short feedback loop, leading to frequent releases. Frequent releases = quick reviews from customers = less time to work in the wrong direction = saving the customer money.

To start development, it is important to have a stated sprint goal and an approved sprint backlog.
Sprint planning is a very important SCRUM activity. Particular attention should be paid to the assessment of tasks, because:
  • this allows the business to understand what functionality it can expect at the end of the sprint. Let's be a predictable team and be "on the same page" with the customer
  • the value of a half-story realized is zero, therefore all stories planned within the framework of one sprint need to be decided.
According to the books in Scrum, you can not change the composition of the sprint. And you need to try to follow this rule as much as possible. But in life, everything is not quite so, and you need to be more Agile. If suddenly the customer needs for objective reasons faster and the team estimates that this is possible, then sometimes you have to adapt to circumstances and realities. The main thing is not to make it a chore, but to manage it, which is what our project managers usually do.
Most often, poker card sets come to the rescue. They allow in a game format to make all members actively discuss the implementation of a particular task, which will enable you to discuss all the nuances and decide on the time to complete the task. Each developer, whether a beginner or a senior, can layout the card with the number that seems to him the most real for the implementation of some task, and then he explains why he thinks so. Here you can hear moments that someone did not know about or find an easier solution that someone has already put into practice.
As a result of the planning meeting, we have a sprint backlog that you can work with.

So, the sprint is running, and the work is in full swing. It is time for daily rallies or stand-ups. Scrum is a story about effective communications that help save team time and effort. These are not just "meetings" and "conversations." They do not take up time that could be spent on work, they are the very work because they help optimize efforts. One of the principles of SCRUM is: "People and interaction are more important than processes and tools."

Right, some restrictions should still be followed. So that people do not get stuck in long dialogues and discussions with a bunch of questions to each other, we determined the time needed for the stand-up - 15 minutes.
They also decided that:
1) each member of the team will prepare for the meeting, namely, write down everything essential for him to share with the team

2) leave a pool of questions for a specific person or team as a whole, which they will discuss after a general meeting.

This was invented to facilitate the communication process of developers and bring them into a constructive dialogue. The project manager monitors the execution of this procedure and that all issues raised are discussed. Thus, the person is not left alone with the problem, and they are quickly helped to solve it most efficiently.
During development, additional questions can always arise, which are usually answered by either the product owner or stakeholders.
SoIt is very important to ask such questions, report difficulties, or sudden situations to the whole team.
After the sprint is completed and all the planned tasks are implemented, the sprint review procedure is ahead. A few days before the end of the sprint, we deliver a new version of the product to a demo server and transfer it for business testing to all interested parties, and we are conducting a discussion. Sometimes it happens that there are difficulties in solving a problem, and it cannot be completed on time - we warn the customer about this and send the task for completion and delivery in the next sprint. Therefore, by the time of the meeting, everyone is more or less likely to think that the team succeeded.
Sprint review most often occurs by remote calling. Usually, it turns out that it involves stakeholders, product owners, and our manager, who tells and shows what has been done. Often, developers are not included in this process - the thing is that with most of the clients, we have a time difference. If the customer does not mind, then we release the team to engage in personal life in the evenings of phoning. There are times when the client wants the developers to take part in the call too, and it is important for him to ask some questions - then the whole team joins the communication. During the call, the client says what suits, and what doesn't, what aspects can be improved. And so - for each user story that was planned for this sprint. Typically, such discussions are held positively. The fun part of the conversation is the collection of thanks and recommendations for improvement from customers.
Together with the whole team, we can analyze and adjust our plans and ideas about the further development of the product. Every member of the team from the stakeholder to the developer strives to make a quality and useful product.
So, the sprint is over, the client is satisfied - the time has come for a retrospective - an important activity within the team. To do this, we resort to Learning Matrix. In the course of such a retrospective, we can openly discuss the positive and negative moments that have occurred to us during this sprint, share ideas on improving processes, and express gratitude to each other. This is very pleasant and, more often, stage motivating the team.

You can think and describe the work according to the Scrum methodology for a very long time. It's worth noting that this methodology requires the active inclusion of all team members.
We strive to help our customers work better, automate various business processes, save money, and be sustainable in development.

It seems that all this takes a very long time, but with a good organization, all this is beneficial and positive.
If you like our process, let's discuss how we can apply it to your project. We are ready to build a convenient process that is right for you! Contact us!
Did you like this article?
Share article on social networks
Worked on the article:
Juliana Amelina
Deputy Chief Executive Officer
Maria Ilchenko
PR and Event Manager
Made on