How do we make a scrum, and what comes of it
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
"Democracy is the worst form of government, except for everyone else." Winston Churchill
"Democracy is the worst form of government, except for all the others.." Winston Churchill
Churchill did not mean, of course, that it was a flawed 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
Churchill did not mean, of course, that it was a flawed 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, this methodology is most popular in the area of programming.
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, this methodology is most popular in the area of programming.
WikipediA
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 team or client's working conditions.
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 developing 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 route's length is not yet known, and you need to pay for this way now.
At this stage, it is essential 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 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 team's formation.
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 team or client's working conditions.
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 developing 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 route's length is not yet known, and you need to pay for this way now.
At this stage, it is essential 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 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 team's formation.
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 essential part of the team is the developers (our superheroes), who must possess the technology stack and qualifications necessary for this project and communication skills. As a rule, we have a self-organizing team, each member of which can carry out any task, not afraid of putting ideas forward, because according to the values of Scrum, the voice of each team member is essential, and there is no clear hierarchy in it - the boss and subordinates.
Of course, an essential part of the team is the developers (our superheroes), who must possess the technology stack and qualifications necessary for this project and communication skills. As a rule, we have a self-organizing team, each member of which can carry out any task, not afraid of putting ideas forward, because according to the values of Scrum, the voice of each team member is essential, and there is no clear hierarchy in it - the boss and subordinates.
By the way, there is no such a concept of a project manager in pure Scrum, but there is arole of a scrum master. His task is to help get all the team members to the goal. He is a forger, psychologist, trainer, mentor, assistant, "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 tasks prioritizing ;, they can add technical tasks and explain to the product owner why they are 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.
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 tasks prioritizing ;, they can add technical tasks and explain to the product owner why they are 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.
More recently, we began to write custom stories using the Gherkin language. This was the right solution and enabled describing the problem in more detail, leaving almost no possibility that the person deciding it could interpret something differently from what was supposed. 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 vital 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: As a big fan of hamburgers, I want to get a burger of three components in a paper wrapper (final result) in order not to get my hands dirty (motivation)
Acceptance criteria in this case:
1. I have a hamburger with meat, bun, and cheese
2. The burger wrapped in paper
The next important step is sprint planning.
Acceptance criteria in this case:
1. I have a hamburger with meat, bun, and cheese
2. The burger wrapped in paper
The next important step is sprint planning.
Sprint is a period after which the customer receives a very useful, albeit small, but functional product. 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 adjust their plans often. A short sprint means a fast 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 essential to have a stated sprint goal and an approved sprint backlog.
Sprint planning is a vital SCRUM activity. Particular attention should be paid to the assessment of tasks because:
Usually, our sprints last two weeks. Short sprints are comfortable. They allow the team to be as "flexible" as possible: ready to adjust their plans often. A short sprint means a fast 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 essential to have a stated sprint goal and an approved sprint backlog.
Sprint planning is a vital 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 completed.
Most often, poker card sets come to the rescue. They allow all members to actively discuss the implementation of a particular task and decide on the estimated completion time. Each developer, whether a beginner or a senior, can choose 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 a more straightforward 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.
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 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 help optimize efforts. One of SCRUM principles is: "People and interaction are more important than processes and tools".
But some restrictions should still be followed. People do not get stuck in long dialogues and discussions with many questions; we determined the time needed for the stand-up - 15 minutes.
But some restrictions should still be followed. People do not get stuck in long dialogues and discussions with many questions; 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 checks whether all the issues raised are discussed. Thus, the person is not left alone with the problem, and can get help to solve it most efficiently.
Additional questions can always arise during development, and they are usually answered by either the product owner or stakeholders.
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 checks whether all the issues raised are discussed. Thus, the person is not left alone with the problem, and can get help to solve it most efficiently.
Additional questions can always arise during development, and they are usually answered by either the product owner or stakeholders.
It is crucial 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 forward the task for completion and delivery in the next sprint.
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 forward the task for completion and delivery in the next sprint.
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 most of the clients are located in another time zone. Sometimes the client wants the developers to take part in the call too, and it is vital for him to ask some questions - then the whole team joins the communication. During the call, the client says what is accepted and what is not, what aspects can be improved. 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 product's further development. From the stakeholder to the developer, every team member strives to make a quality and useful product.
The sprint is over, the client is satisfied - the time has come for a retrospective - an essential activity within the team. To do this, we resort to the 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, motivates the team.
You can think and describe the work according to the Scrum methodology for a very long time.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.
You can think and describe the work according to the Scrum methodology for a very long time.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. Contact us!
If you like our process, let's discuss how we can apply it to your project. 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
