Working with Scrum

User Story

User stories are an effective way to state requirements for software in development. Such stories contain brief advice on behalf of the user of the software.

Since in the Scrum methodology, setting goals is usually the prerogative of the customer or software owner, they are considered the main way to influence the development process. Each User Story has a limitation in the amount of text and the complexity of presentation. History is most often written on a small sheet, which in itself limits the volume.

Thanks to user stories, you can document the wishes of the client and quickly respond to market demands.

The User Story should be considered a simplistic measure of requirements because it does not include an acceptance testing procedure. The compilation of the user story must comply with the admission procedure. This will ensure that the User Story achieves its goal.

The story structure looks like this: “As a user <user type>, I want to perform <action> to get <result>” (As a product owner I want ...). Such a structure is not only simple, but also understandable to everyone.

Benefits of using User Stories:

• Stories are small and easy to create.
• Help all stakeholders to discuss the work on the project and its support.
• Do not require constant maintenance.
• Relevant only when used.
• Improve interaction with the client.
• Thanks to them, you can divide the project into small stages.
• Facilitate work on projects with poorly understood requirements.
• Simplify task evaluation.

Disadvantages of User Stories:

• Without prior agreement, procedures can make it difficult to use as a basis for an agreement.
• Their use requires close contact with the client throughout the entire project, which sometimes makes the workflow difficult.
• They have disadvantages when scaling on large projects.
• Directly related to the professional level of developers.
• Used to start a discussion, but may not end a discussion, and are not used for system documentation.

Backlog

The product backlog is the current tasks in the form of a list, compiled in order of priority. The list is formed on the basis of the roadmap (roadmap) of the project and the points set out in it. The most important tasks are usually at the top of the list. This is necessary to understand which work should be done first.

The development team chooses the speed of completing backlog tasks regardless of the wishes of the customer, but based on their qualifications and experience from past sprints. It is extremely undesirable to “adjust” programmers. The team itself chooses tasks from the backlog according to its own considerations and capabilities. Execution takes place without interruption (Kanban) or several iterations (Scrum).

Two important backlog conditions

The core of a product backlog consists of a roadmap, proposals, and execution conditions. Epics contain conditions and User Story. Let's take a close look at a typical roadmap example.

Creation of the “Teams in Space” website is the first proposal from the roadmap. It needs to be divided into epics (in the figure they are shown in green, blue and turquoise colors) and a User Story for each epic.

The software customer forms one list from several User Stories. If necessary, he can change the order in which the stories are executed, so that the developers will first deal with one of the most important epics (left) or check how discounted ticket booking works. To do this, you need to implement stories from epics (right). Both options can be seen below.

Based on what factors should the customer prioritize?

• Relevance to users.
• The presence of feedback.
• Complexity of development.
• The relationship between tasks (to complete "B", you first need to do "A").

Priorities in the work are determined by the customer, but other parties can express their opinion about this. The success of the backlog depends, among other things, on the opinions of customers and programmers. Together, they can achieve better results and ensure timely delivery of the finished product.

How to keep a backlog

If the backlog has already been created, then after that you need to periodically change it in the course of further work. The software customer should make sure that the backlog is properly compiled before each new iteration planning. This will help clarify priorities or change something after the analysis of the last iteration. Adjusting the backlog in Agile is sometimes called “grooming” or “refinement” or “backlog maintenance”.

If the backlog is already relatively large, then the customer needs to group tasks by short-term and long-term execution. Short-term assignments should be scrutinized before they are given this status. You will have to compose a User Story, find out all the nuances within the team.

As for long-term tasks, it is highly desirable that the developers give them their assessment. This will make it easier to prioritize. Perhaps something will change, but the team will improve their understanding of the tasks and get the job done faster.

The backlog is an important component between the customer and the programming team. The customer can always change priorities based on customer feedback, forecasts, or new requirements.

It is recommended to avoid making changes directly during operation. This has a bad effect on the workflow and the emotional state of programmers.

Sprint

A sprint is a short period during which a previously agreed amount of work must be completed. Sprints are based on Scrum and Agile methodologies. Choosing the right sprints helps an agile team develop quality software.

“Using Scrum, you can develop a product in several iterations with a clear duration - sprints. It helps break large projects down into smaller tasks,” says Megan Cook, Jira Lead at Atlassian.

How does Scrum plan and execute sprints?

According to the authors of the Scrum methodology, in order to plan the future sprint, everyone needs to meet at a separate meeting. At this event, team members must find answers to two main questions: what needs to be done in this sprint and how best to do it?

The software customer, Scrum master and programmers are involved in determining the list of work tasks. The customer explains the goal of the sprint and tasks from the backlog.

Then the team develops a plan according to which the tasks in the sprint will be completed. This plan, along with the selected work items, is called the sprint backlog. After the planning meeting, the team gets to work. Developers select tasks from the backlog, as the work is completed, the status of each task changes from “In Progress” to “Done”.

During the sprint, the team holds daily Scrum meetings (stand-ups) to discuss current issues and progress. Such meetings are needed to identify difficulties that can affect the completion of the sprint.

If the sprint is completed, then the team shows the results of their work on the review of the results (demo). Each participant of the project can get acquainted with the results. Familiarization should be done before the finished code is merged into the production environment.

The retrospective completes the cycle of sprints. On it, the team identifies areas that need to be improved in a future sprint.

What to pay attention to and what not to do

Most young teams find it difficult to introduce sprints into their workflow for the first time. To avoid problems, we recommend that you review the list of actions that need priority attention.

What do we have to do:

• Check that the team understands the purpose of the sprint and how it will succeed. This is necessary for everyone to move towards a successful result together.
• You should have a clear and understandable backlog. If the backlog was not maintained correctly, this can become a problem that can damage the workflow.
• Make sure that your estimate of the pace of work is correct, taking into account summer holidays and other factors.
• Actively participate in sprint planning. Encourage team members to expand the plan for stories, bugs, and assignments.
• Refuse tasks during which developers will not be able to resolve dependency issues.
• After the plan is approved, appoint an employee who will be responsible for entering data into the project management program (Jira cards, etc.).

What to avoid:

• Do not overuse a large number of stories, soberly assess the pace of work and do not assign tasks that will be difficult to complete in a sprint.
• Be mindful of the quality of your work. Check if you have enough time for quality control and fixing bugs in the code.
• Make sure all team members clearly understand the content of the sprint. Don't chase speed. The whole team must move together.
• Don't overburden developers with extra work. Another sprint coming soon.
• If the team expresses concern about the workload or the deadline, you should take into account their opinion. Deal with problems and correct them if necessary.

scrum board

The Scrum Board is a tool that shows how the work of the Scrum Team is done. You can display information on such a board on paper, on the wall or in electronic form (JIRA, Trello).

A Scrum board has at least three columns: To Do, In Progress, and Done. Here is an example board:

The Scrum board contains all the information from the backlog previously approved for planning. As a rule, business task cards are pinned to the board by priority from top to bottom. You can divide them into specific types of work (work on code, design, and others).

After part of the work is completed, the card is moved across the board to the next column. To show the visibility of the progress of the team’s work, the “remaining work” by day on the Burndown Chart helps.

You can also use a flipchart board. On it, the names of the works are written on paper stickers and attached to the board. As soon as the work is completed, the stickers are moved to another column.

burndown chart

The burndown chart shows the amount of work done and the amount of work left. It is updated every day and is available to all interested parties. The graph is needed to show the progress in the work on the sprint.

There are two types of charts:

• Burndown chart showing the progress of work in a sprint.
• Burndown chart showing the progress of the work until the release of the product (data is summarized from several sprints).

Chart example:

This example uses psychology: the chart does not show the number of completed tasks, but the number of remaining (not done).

That is, if the team has done 90 tasks out of 100, then there may be a false feeling that everything is ready. After all, progress from 90 to 100 tasks doesn’t really change anything.

If you display the number of remaining tasks, then you can not help but notice how each time they become less and less. This subconsciously spurs the project participants to achieve the goal faster - there should not be unfinished tasks on the board.