Scrum in practice

Back in 2013 after reading a lot about Scrum and Agile, I got my first chance to be a Scrum Master. Now in 2021 after experiencing product manager/product owner in many projects I got to be scrum master again. Nowadays there are many more documents explaining agile concepts and how Scrum and Kanban works. But most of them are focusing on general ideas and high-level actions.

It’s surprising still there are few articles and sharing experiences about scrum in practice and how actually teams handle those concepts. In this article, I am gathering myself and others' experiences as a handbook. I hope it helps to use other experiences instead of discovering them from scratch.

Planning

It all starts from here. a meeting where all team members are gathering. You will have the Product Owner (PO), team members, and the scrum master.

Step by step

Prepare Backlog

Before the meeting, the PO or any other team members add user stories to the backlog. They should have a clear description and acceptance criteria (AC). Any team member should be to evaluate ACs.

Estimating each task/user story

During the planning, for each user story, the related person needs to explain first. After that everybody will ask questions until it’s completely clear. Maybe some items are not related to the whole team, still, it’s useful to have all participants in. First, they may affect the overall concepts and understand how other parts work, second, they can get more align about task logic and how they are breakdown.

After a complete discussion, you can use the poker game to estimate the task. You can use apps, slack app, your fingers, or physical cards. All are the same.

Story point

We use story points to estimate how hard is the user story. It’s a number, from 1 to any range. Usually, we use Fibonacci sequence: 1,2,3,5,8,13. This number must show a combination of time, complexity, and other parameters. But how? it’s just comparing. Usually, you can say how hard is a task is, in comparison to the other one, but it’s hard to say how many days it needs? Here we saying: A is 3 and B is 5. It just means B is harder than A. So either it takes more time, needs more focus, or more research. As you can see, for the starting sprints, you need to train the team to find out their best balance.

More than 13 means it’s too complex, so you need to break it down in more detail. We also use ∞ for tasks we feel are still too complex,? for items which we need more input or it’s not related to us. e.g. You are a backend developer and some frontend part is estimating.

Capacity

after 2–3 sprints, you can find an average on the total amount of user story points the team can complete. This average becomes more meaningful after each sprint. The average + 20% more, usually consider as team capacity.

It’s true any time you don’t have the same man-days, someone is sick or vacation, or adding new team members and so on. Here you are just trying to make an estimation and it’s fine to not consider this kind of errors.

best practices

Adding a new task/user story:

In some teams, only the PO and tech lead are allowed to add user stories. It helps to have more discipline on tasks and you're sure at least one of these two people knows all items in the backlog. Otherwise, it will bring an overhead to PO and team lead.

Sorting the backlog before the meeting:

It’s better to sort the user stories based on priority before the meeting, so during the meeting you will first discuss the most important ones. It’s possible to change the priority during the meeting. The team members can add, edit, or merge the user stories during the planning.

Story point:

• It’s better not to have 13 or higher in the sprint. Besides set limit for story points of 8 or even 5, e.g. max one 8 and 3x 5 (depending on the velocity). In this way, you will have a better burndown chart and better details on user story definition.
• For the 2 first planning, it’s normal to change the story point a lot. Just remind everybody, it’s not time or man-day. Continue to compare new estimations to the past one. But after some planning session stops doing that. The team will do it on their own.
• Some teams for beginning consider story point as hours and later they change them to real story points. It’s very useful when the team has limited experience with Scrum, or there is a lot of doubts about the amount of story point for each task.

Team members:

• If on each task just a few are involve and there is no connection between them, maybe you need to change team structure. If they are not working together, they are not a team.
• In the ideal case, you don’t assign tasks to each person. But in some cases, there is just one person who can do it or it’s clear who is the best person to cover it. In this case, make sure not to make too many tasks for one person per sprint.

Daily

After completing the planning, the whole team starts working on the tasks. Every day at the time you all agree on that all meet each other, very shortly each person will explain what s/he did and what about today? If there is a conflict or important topic which others must be informed of, it can be explained in the meeting.

It’s better to have a standup meeting to limit the time. It must not proceed more than 15min. It’s not a formal and heavy meeting and nobody must feel overhead from that.

At the time of the meeting, it’s better to be a time before most of the team starts to work. So most of the team will not be interrupted in the middle of their work and also each person needs to decide what s/he is going to do today.

Best practices

• We mostly do the meeting at 10 am or 11 am. Since most of the developers are not early guys.
• It’s better to use a random sequence of who talks first, for physical teams you can use a ball (or anything else) so each person who goes next. Or anyone prefers to continue after the current person.

Grooming

When you are developing a product, there are product needs that convert to technical issues. The grooming meeting is the place product manager or product owner explain their needs, and the team suggests how to convert them into tech tasks.

best practices

• Usually, it’s recommended to have the Grooming one week before the planning. So there will be enough time to find the answers and also not long which cause priorities to be changed.
• You can ask extra people for Grooming, for example, experts in the industry you are working on.
• Put enough time on Grooming, there is no problem to have +2 hour meeting. Just make a break to keep it all fresh.

Retro

The retro meeting is the place to hear everyone, what’s nice, what’s wrong, and decide to change the process. It’s important to make sure to know what’s not working and fix it as soon as possible. It’s not necessary to have retro every sprint, you can have it every month, or after each major release.

Step by step

What went well

First, everyone should think about what went well and they are happy about it. It’s important to give enough time so everyone can think and write down what’s in their mind.

What to improve

In this part, we rise the problems and parts you feel it’s not right. It’s important to ask for more details as much as possible to make it clear and of the chest.

Actions

As a result of discussing on “need to improve” we need to make clean action items. The action must be feasible and satisfy the team. You can set responsible for each action item to make sure it will be followed up.

best practices

• Before reviewing each part, combine related items. Either collect related tickets in one location or just merge them.
• Ask guys to vote, but limit the number of votes. You need to make sure what are the most problems or strengths your team has.
• If you are managing a remote team you can use one of the online boards:

FunRetro | Improve your team with fun sprint retrospectives

Or any other general boards like Miro, Trello, etc.

• In one team we add the Kudos part, to say thanks directly to a team member who helps us or did something nice. It really helps with team building.
• It’s nice to have retro outside of the office to make it more unofficial and breaking ice for the team to talk more freely.

Sprint Review

After each sprint, it’s good to review what happens in a sprint.

Step by Step

First, you need to review all tasks, which one is done and which one is not.

Second, you need to close the sprint, move “not done” tasks to the backlog, and review the main KPIs. In the beginning, a capacity has been estimated, how much of that has been met?

Third, have a demo. On each sprint, you have goal(s) to achieve. Now team should show what they have done, get feedback, and see how much they achieve that goal(s).

Best practice

Invite others to see the demo. Other key people related to the team outputs, including customers, other teams, or managers inside the company. This is the best place to get feedback and update everyone on what you are working on.

Additional points

• It’s totally fine to have a 1 or 3-week sprint. It’s up to you and your time.

Any other ways?

I am sure there are many other ways many are trying.

If anything you think is wrong, or you are doing it differently please let me know. I will add as much as possible.