What is Scrum? TRIARE Talks Special
This is a part 2 of TRIARE Talks session in which we focused on Scrum. Our team expert Myroslava Drozhko pointed out that it is one of the most directive methodologies in Agile.
In Scrum, the rules are explained in detail. That is the reason why it is recommended for startup teams, since it saves their time on establishing processes. There is a clear plan one can follow.
The three roles in Scrum:
- Development Team (developers, testers, designers all as one group)
- Product Owner (client or their representative, who will tell about the project, negotiate the requirements, etc.)
- Scrum Master (a person who will manage the process and avoid deviation)
Iteration in Scrum is called a sprint. Usually, one sprint takes from 1 to 4 weeks (the team decides on the length they prefer).
There are 4 major meetings in Scrum, which are repeated with every iteration:
Sprint planning meetings. The team, Product Owner, and Scrum Master discuss the backlog (all the tasks that need to be completed to launch the project) and decide, which tasks to plan for the next iteration. They evaluate the tasks in hours or story points and move them to the sprint backlog. The meeting should be short, around one hour or less. If the team has any questions on the tasks, the Product Owner answers them to establish a clear common understanding of what needs to be done.
Daily scrum (daily meetings). The development team discusses the progress: what is already done, what is planned for today, what issues the team had encountered. Every team member takes turns talking. If anyone needs help, they ask for it directly. If the issue is simple, it can be solved right there and then. In other cases, the team member can schedule a separate meeting with the one who can help solve the issue. Note, that Daily Scrum should not last longer than 15 minutes. The main idea is that the team should focus on their work. They come, express any issues, go back to work quickly, and then the Scrum Master is managing the problem.
Sprint Review meetings (Demo). When the tasks for the sprint are done, the team decides if they can show a demo to the Product owner. The demonstration is held at the Sprint Review meeting. The result you show must be working. From the very first iteration, one shows an MVP and then improves it. What does MVP mean? It is a minimum viable product, something a customer can already test and use. The whole principle of Agile is to deliver value at every iteration. We can reach that due to the iterative-incremental approach (if you have not read our article on Agile, we highly recommend it to understand the basics).
All the stakeholders can come to the meeting (e. g., investors, co-owners of the business, invited users of the future product, etc.) They all leave their feedback. Ideally, we should have some time to spare in our sprint to fix anything according to the feedback. If we lack the time, the tasks are transferred to the next sprint.
Sprint Retrospective. This meeting is held at the end of the sprint. The retrospective definition is, generally, a look back at the past: the events or work, etc. The main goal of this meeting is to discuss if the sprint was successful, what was good and what issues occurred. Then, we can analyze how to avoid the same issues in the next sprint. Additionally, team members can offer their suggestions.
What is a Scrum board?
Myroslava reminded us that the Scrum board is a visual (online or physical) representation of the work to be done. It has started as a physical board with stickers. Today, many online applications help organize everything better, especially in large teams. The board is usually divided into the following columns: backlog (all the tasks), sprint (tasks for a particular sprint), to do, in progress, verify, done. As the work progresses, stickers migrate from one column to another. You can add other columns specific to your project if they help organize the flow better.
How to write tasks?
The speaker explained that user stories are a common approach in Agile to formulating tasks. They are written as follows: “As a <user/who> I want <action/what> so that <purpose/why>”. For example, “As a potential customer, I want to read product reviews and ratings, so that I can decide what to buy”. The last part, about purpose, should contain some business value. If it doesn’t, цу should probably delete the user story from the backlog.
The whole idea of user stories is to turn attention to business value. If the task is totally technical, it should be attributed to the most relatable user story, which contains a business value. In fact, a user story is not a task. It can contain many tasks (small and precise to-dos for developers).
How to estimate tasks?
A story point is a metric commonly used in Agile to evaluate the effort required to develop the user story. Simply put, it is a number that reflects the difficulty level of a given story. The main idea is that story points are better for estimation than hours. It is difficult to predict the precise number of hours and minutes for a particular task especially if the team is young and lacks experience. That is why the clients are often disappointed, which is unnecessary.
Planning Poker is a widely used practice of story point’s attribution. It looks like a board game with cards. Cards represent story points as a sequence of Fibonacci numbers: 1, 2, 3, 5, 8, 13, and so on. When the team, Scrum Master and Product Owner gather on the Sprint planning, team members each get a set of cards. The tasks are briefly summarized and evaluated, one-by-one. Each developer shows a card with the story point for a particular task. Then everybody discusses the results (why is the task more or less difficult?) and comes to a common conclusion about a story point for the task. The meeting continues until all the tasks are evaluated.
How to track progress?
To better allocate resources, there is a number called Sprint Velocity. It reflects how many story points fit the sprint. If we don’t use story points, there is a Team Capacity – the number of hours a team can spend on one sprint.
One of the basic metrics used in Scrum is a Burndown Chart. It is a graphic representation of the speed of the team’s work. The y-axis is attributed to time (hours, days, or story points). The x-axis reflects the iteration timeline (the length of the sprint). The chart represents the ideal straight curve of effort to compare with the actual curve. It is filled out every day, and if the curve slopes upwards, one can at least warn the customer about the delay.
What is a Scrum certification?
Our coach shared that there are a number of certifications one can receive as a Scrum Master, Developer, or Product Owner. There are also general programs, like those about Scaled Professional Scrum or Scrum with Kanban. Moreover, there are different levels of certifications, from Beginner to Advanced. All these certificates can be obtained through studying and examination at different organizations. If we feel the need to advance our career, or we want to learn more about this detailed and efficient system of work, Scrum certification might be the answer. However, she recommended choosing the organization thoroughly.
Myroslava expressed her hope that this overview of Scrum had been helpful. We hope too for you. Share your thoughts with us and let know if you have any questions.