Created in 1995 by Ken Schwaber and Jeff Sutherland, scrum is the most used agile project management framework (different methodology) in the world and uses modern working concepts. We are not going to detail the history of Scrum here (click here to learn more), but in its practical concepts.
Basically Scrum transforms the method of managing cascading projects (those well designed in MS Project with Gantt charts) and breaks it into parts (multiple parts) which are sorts of "mini projects", also known as "sprints". What stands out the most in Scrum is the fact that it allows small functional deliveries to the client.
After all, why use Scrum?
If you have the responsibility of managing a project, whatever it may be, whether this project can be delimited with finish dates or not, you will need to have a working template. There are several models (there are also people who don't use any models), but there are two specific ones that are the most used:
Cascading Models
Waterfall models are those projects in which all phases and activities are planned on dates, one tied to the other. This template creates a well-defined schedule with estimated deadlines and dates. PMI is the organization that sets the guidelines for a project manager. There are many rules to follow and in some companies, a PMI certification is required to be considered a project manager (PM) or work in a project office (PMO).
Agile models
Agile models are those in which there is no concern about delimiting the dates for each phase and task. This does not mean that the obligations do not have a term! The fact is that there is not much concern in estimating the date of everything at the beginning of the project, as the estimate will be made along the deliveries called "Sprints".
Is it just for developing software?
Despite being conceived in the world of software development, Scrum applies to any type of project. Below we will generically detail how this will happen.
How does it work?
There are many illustrations about Scrum, but this illustration below represents ALL elements of the Scrum process.
the backlog
The Product Backlog is a list of all the features that will be developed in the project.
Designing the backlog with Epics and Features
The Product Backlog is composed of items called Epics, which are large steps with description in the customer's language, without much technical detail. Epics can be items in a contract, for example. Features are steps that characterize the Epics and are more technical descriptions, an idea of the conception of the Epics. In smaller projects, Epics are not used and are replaced by Features.
Backlog Grooming
Backlog Grooming is a series of actions aimed at incrementing and prioritizing the Backlog, after all, requirements can change and the Product Backlog needs to reflect this change.
Prioritizing the Product Backlog
Imagine a list of 1000 project items, which should be done first? Scrum is flexible and as it is an agile model, it allows the Product Backlog to be prioritized by the customer at any time and incremented, as new items and new requirements can arise at any time, as well as changes!
Therefore, the Product Owner must constantly update the Product Backlog and keep it prioritized according to the customer's needs and contract specifics.
Creating Tasks
The highest priority items in the Product Backlog need to be analyzed by the technical team and detailed, after all, the items in the Product Backlog are generic, written in a superficial way. Since the highest priority are those that will be developed first, they need to be technically more detailed. From the Features, the technician must create the last level, the Tasks (if it is a software development project, they are the User Stories).
In summary, the hierarchy of items that make up the backlog is this:
the sprints
Like the Product Backlog, the Sprint Backlog is a list of features, however, it is a smaller list with ready-to-work items. To design the sprint, it is necessary to hold a meeting called Sprint Planning, but, first, the items need to be estimated with the team.
Estimating Product Backlog with Planning Poker
It is not possible to create a Sprint Backlog without the Product Backlog items being estimated. There are several techniques for estimating service, but the most common (and interesting) is Planning Poker. In Planning Pocker, the Product Owner takes the Tasks of the highest priority items from the Product Backlog and presents them to the team. For each item presented, the team presents its estimates as follows:
- With cards in the fibonacci sequence , after presenting the item, the team chooses its estimate and at the same time, they play on the table
- If everyone has the same estimate, this is assigned to the item.
- If the team presents different estimates, the reason for who released the lowest and highest estimates should be asked.
- After understanding the discussion, the cards are launched again until there are homogeneous estimates
With all the Tasks of the highest priority items in the Product Backlog estimated, it's time to define the Sprint Timebox.
Sprint Timebox
With the sprint period defined (2, 3 or 4 weeks), we know how many working days will be worked in the sprint. By defining the hours per day dedicated by the people who will sprint, we can know the Sprint Timebox.
Sprint Planning
The Sprint Planning meeting will define the Sprint Backlog, which is a list of items that will be performed in the sprint period. It is for this queue that the team that performs the tasks will look and monitor the demands.
Kanban for routine management
The sprint has started and the best way to organize the work routine is using Kanban. Kanban is a board composed of columns with the Task statuses. As the team executes the Tasks, it updates the status of the Burndown Chart.
Burndown Chart to follow sprint evolution
Burndown Chart is a two-line chart. A line with the ideal trend and another line showing the actual progress of the work. If the actual line is below the ideal trend line, it means the sprint was estimated wrong and the team could have produced more items in the period. If the actual line is above the ideal line, it means that the items were not made within the estimated time. When this happens, the ideal is to end the sprint and put the remaining items in the next one.
Daily Scrum
The Daily Scrum is a daily team meeting. It should take place quickly and within 15 minutes at most. Generally, the team holds this meeting standing up, so that it is agile. At the meeting, the team answers the following questions:
- What am I doing?
- What am I going to do?
- Are there any impediments to what I'm going to do?
The Product Owner must collaborate to solve the impediments.
Sprint Review
The Sprint Review is a meeting to present and deliver the functionality (or part of it) that was developed during the Sprint. In this meeting, the Product Owner, along with the team, presents what was done to the Customer. All those interested in the delivery participate in this meeting.
Retrospective Sprint
The Sprint Retrospective meeting is held by the Team and Product Owner only. In it, the team will discuss what was produced in the Sprint, the techniques used and will brainstorm to identify better ways to do the work and optimize the next Sprint. This meeting also re-evaluates the need for new items that will be added to the Backlog and will likely go to the next Sprint.
The delivery
The goal of Sprint is to deliver something functional to the customer. Delivery may require some ceremony with the client, everything will depend on the project. In addition, the delivery marks a Backlog item as completed , but what must not be forgotten is the fact that this delivery must "add value" to the customer and solve the problem (or part of the problem) for the customer. After all, agility cannot fail to consider quality.
Startup photo Stock Photos on Pexels
To go back
