From the desk of a brilliant weirdo #1:

Thanks for checking out this article, mate! It really means a lot.

Let’s get down to brass tacks.

This is an article about scrum ceremonies.

I’ll cover the 5 types of scrum meetings.

Each scrum ceremony -- be it the daily scrum, the scrum retro, the sprint planning, the sprint review, or the backlog refinement -- is timeboxed. Some span from 1 to 2 hours, while others may go up to 8 hours.

I’ll also slightly talk about the scrum model, scrum process flow, scrum values, and anything else that falls in between, and how to make it better.

Without further ado:

Daily Scrum

The attendees of the daily scrum include the scrum team, the scrum master, and the product owner.

Many teams don’t realize that the daily scrum is made for the team as a whole, not for a single person (the Scrum Master or the Product Owner). As a result, many teams cancel their daily scrum when the scrum master or the product owner can’t attend the meeting.

Some developers believe that daily scrums are made to benefit only the managers by keeping them in the loop. But that just shows how impartial they are.

If you think about it, developers are communicating with each other 24/7; hence know what’s going on.

For the scrum master to be kept in the loop, he must participate in the team’s daily collaboration. He shouldn’t drain out the team’s energy by turning the daily scrum into a reporting session to get a bare insight into the team’s progress. There are burndown and burnup charts for that purpose.

Daily Scrums are held for team members to share what blocks they’re facing so other members of the team can provide help.

Parroting your sprint schedule during the daily scrum is simply a waste of time. Everybody can see what you’re up to by checking your sprint calendar. Instead, daily scrums should be focused on solving problems.

Sometimes, however, it’s hard to make developers admit what obstacles they’re facing. That’s because the impostor syndrome quietly arises in their minds, telling them they might look stupid in front of their peers that they want so desperately to impress.

Yet…

...there are still developers out there who advocate the daily standup

And would rather attend a 15-minute meeting each morning than have somebody hover over their work desk every half an hour just for “quick sync up.”

If the team isn’t doing any standups at all, it’s easy for developers to get “isolated” and blocked out. Occasional daily scrum meetings can bring them back in the loop.

Standups can also be useful when you’re onboarding new team members.

Some teams have found great success doing their daily scrums over Slack via chat.

Still, you gotta...

approach daily scrums differently if you want to make them more productive

In the very beginning of the meeting, you can make every team member share if they are facing any obstacles keeping them from making progress.

Then, only developers who want to elaborate on their problems or provide solutions can stay; others can hop off the meeting and get to work.

Daily scrums can rarely bond your team though.

The best thing you can do to build a strong relationship with your teammates is to take them out on a Friday night, drink a bevvy, have fun, and then switch over to tequila shots.

Here are the main killers of your daily scrums:

• Team members showing up late.
• People aren’t saying too much.
• Others don’t know when to shut up.
• People complaining about how bad the daily scrum is.
• If the SM (scrum master) can’t attend, the daily scrum gets canceled.

As an aside: 90% of developers hate to track their sprint hours of operation using time tracking software.

Focus on results not on sprint working hours, and you’ll have more success with your projects and your team in general.

Yet, sometimes, the problem isn’t with the daily scrum but with the company’s culture.

Scrum Retrospective

The sprint retrospective is considered to be the most important scrum ceremony of them all.

It allows us to improve our working flows and thus deliver awesome results at the end of every sprint.

Usually sprint retrospectives are held right after the sprint review at the end of the sprint.

For a month-long scrum sprint lifecycle, a scrum retrospective’s timeline can span from 3 to 4 hours.

Scrum retrospectives can be great for clearing up bottled up feelings and emotions. Don’t let your team burnout; instead do a retro, and clear things out.

Taking notes during the retro can be considered as a “scrum best practice.” Note down what went great and poor. And then create a list of action items for improvement.

Make your retros enjoyable

Most times, retros will turn into boring blabbering that nobody wants to attend.

Encourage not-work-related talks where teammates can share cool stuff with each other and strengthen their relationships; thus build a better sprint team.

Bringing snacks and other yummy-yummy stuff to the sprint retrospective can boost the team’s spirit and create a supportive atmosphere.

Don’t allow a “bully” attitude though. Retros should feel like a safe place where everybody can share their concerns.

Treat each other with respect and focus on fixing problems instead of blaming others.

Don’t create a “YES” culture

If you’re only talking about the positive stuff and neglecting real problems, you’ll end up running in circles and making no real progress.

Address all the negative shit but keep the positive attitude on point - “everything is figureoutable.“

Don’t let only one or two team members dictate the pace and direction of the meeting. Every single member of the team should be active during the retro; that way, it feels more energetic; it bonds the team.

You can suggest that team members jot down their thoughts on notes before the scrum event if that would make it easier to participate in the conversation.

The 4 scrum stages of the sprint retrospective

1. Set the stage

Setting the stage is a scrum activity that’s vital to the success of the retro.

You can elevate the team’s mood by starting the scrum ceremony with a round of admiration. Basically, tell your colleagues what you must admire about them.

Also, before the retro, you can spend some time going through email threads, chat logs, tickets, and other communication channels, and gather all kinds of quotes.

Write them down along with the owner of each quote, and make the team guess who said them. Quite often, the team will guess right and even recall the situation in which the quotes were mentioned.

And, of course, one of the most thoughtful questions you can ask is, “Why are we doing this?” The answers might surprise you.

2. Gather information

You can use the mad, sad, and glad technique here.

Draw 3 columns and place the words mad, sad, and glad on top of each one.

Make the team write down events, on sticky notes, during which they felt mad, sad, or glad. And then you can ask the following questions:

• What was difficult about this user story?
• What was the fun part of it?
• Did you see any repeating patterns?
• Do you have any suggestions on how to handle similar situations in the future?

You can try the “speedboat” method. Draw a speedboat. Attach a strong motor to it and a heavy anchor.

Then each member of the team should write down, on sticky notes, what propelled them to move forward and what held them back. Just one idea per note. Attach the sticky notes to the motor and the anchor respectively.

Read them out loud and discuss ways to increase the motor’s horse powers while cutting down the anchor weight.

3. Collect insights

If you are facing difficult problems throughout the sprint, you can think about what would be different if all of those problems didn’t exist; share your insights with the team. It’s actually great practice for the entire scrum team. It generates a healthy discussion about removing roadblocks.

Asking some of the following questions can be quite helpful as well:

• What went well this sprint?
• What did we learn?
• What should we do differently next time?
• What still confuses us?

4. Make a decision

The final scrum activity. Near the end of the retro, you can hand out a pencil and paper to each member, and tell them to write down two action items for the next iteration.

After that, every member of the sprint team should pair up with the one sitting to their left; thus forming a group of two. You now have 4 action items in a group. Then each group should narrow down their action items to only two again. Repeat the same with groups of 4 and 8 until there are only two action items left for the entire team. Then you either implement both actions items or vote for one.

Sprint Review

According to the Scrum guide, the sprint review session is held at the end of each sprint.

This is not a formal meeting, nor it is a status meeting. It’s held to encourage collaboration and make the team operate as a whole so it can grow.

It also allows developers to showcase their work to upper management and other stakeholders; thus receive feedback and improve the way they approach work in future sprints.

The main participants in this scrum event are the developers, the scrum master, and the product owner. Other teams and stakeholders can take part as well.

During this scrum ceremony, the dev team reviews what went well, wrong, and how team members handled difficulties throughout the sprint.

As opposed to the scrum retrospective where “the how” is discussed...

…the sprint review is a discussion about the “what”

What’s been done during the sprint?

This scrum session, unlike the retro, can last as long as it needs.

The sprint review shouldn’t be led by anyone as this poses the risk of “crowding out” team members that would have otherwise made great contributions to the meeting. The Scrum Master’s role and responsibility are to facilitate the sprint review, and the demo work is presented to stakeholders by the PO.

Neither the PO nor the SM should take credit for the dev team’s work though.

The demo presented during the sprint review is not a demo from the local environment, it’s a demo from the actual production stage.

During the demo work showcase, you may want to answer the following questions to find out whether the sprint release was successful or not:

• What did the customers like about it?
• What did they dislike?
• What’s hard to understand from a customer POV?
• What changes do they want?
• What new features do they want to be added?
• Has the market changed? Do they have different problems?

The nasty mindset

Some developers bear the mindset that any time spent on anything other than coding is wasted time.

This, although the right way to think at first glance, can be detrimental to the team’s success.

Heading over to the code editor without doing any initial planning in advance will take you nowhere near to your desired destination.

During the sprint review, the team should talk about how the market reacted to the new release, and then offer suggestions to improve the product.

The result of a completed sprint review meeting is a revised product backlog that lists all the potential PBI items for the next sprint.

This doesn’t mean that the product backlog items are set in stone though; the product backlog can be frequently adjusted, especially during the sprint planning session for the next sprint.

Sprint Planning

For a 2-week scrum sprint cycle, the timeline of a sprint planning meeting may last between 1 and 2 hours, and can go up to 8 hours for longer sprint cycles.

As the name suggests, sprint planning is about coming up with the complete sprint plan for your next iteration.

According to the Scrum guide, There are 2 main questions that the sprint planning ceremony:

• What can be delivered in the Increment resulting from the upcoming Sprint?
• How will the work needed to deliver the Increment be achieved?

The team spends a serious time of selecting the right PBIs (product backlog items) and then ordering them by priority in the sprint backlog.

It’s important to note that the items in the sprint backlog aren’t commitments; they are merely forecasts.

If the team is to commit to the sprint backlog, it’ll burn out, and provide a poor-quality product.

Most teams break their PBIs in smaller tasks that would take them no more than 2 days to complete each. This makes it easy for the team to track its progress; it also keeps them motivated.

Here’s an example:

You’re building a car, and one of the PBIs is the driver’s door. Smaller tasks would be to paint the door, put a handle on it, fix it to the car, etc.

The sprint goal

The sprint goal is discussed during the sprint planning meeting. It’s a goal, set by the team at the beginning of the meeting, that guides the team throughout the sprint.

Keep in mind that a mature scrum team is supposed to deliver between 85 and 115% of the planned work every sprint.

With time, you can see whether you overdeliver or underdeliver. If it’s the latter, then you’re biting off more than you can chew. If the previous, add more work to the backlog.

It’s a rule of thumb that a new team with a new backlog should allot 10% of its capacity to build out the product/sprint backlog before the start of the sprint. Experienced teams spend less than 10%.

A well-designed sprint backlog is mainly based on data and previous performances, not on whimsical thinking.

Also, at the start of the sprint planning session, the team should review the scrum artifacts from the previous sprint and decide whether to include them in this new sprint or not.

Keep in mind that items from previous sprints aren’t considered to be the main work of the new sprint. No points should be credited to completing work from previous sprints.

Try to observe the product from the eyes of the customer. What are the customer’s problems and desires? What do you need to develop to solve their problems?

The main purpose of the sprint backlog is to guide the development team along the way, it’s not to make the team over-commit and then burn out.

Backlog Refinement

Backlog refinement meetings are unofficial sprint events that are held a couple of times throughout the sprint.

The main purpose of this scrum ceremony is to detail, improve, estimate, and prioritize the PBIs in the sprint backlog as changes occur.

The typical duration of a backlog refinement meeting can span from 1 to 2 hours.

The PO and at least one member of the team are the required attendees for this meeting to happen.

This doesn’t mean other people can’t attend though. The rest of the scrum team along with key stakeholders can also be present at the meeting.

Each item in the backlog is thoroughly discussed, and if it makes sense, its description, order, or values are changed.

To make the meeting as productive and time-efficient as possible, the Scrum Master might want to keep track of the time spent on discussing backlog items.

You can set a time limit, of 10 minutes for example, per each backlog item.

If you find yourselves talking about an item for too long, you can delay the discussion for another time when you have more time and are better prepared to make suggestions.

Don’t waste time on tiny details

Things will change, and you’ll need to do another meeting.

Scrum is an empirical process and stands for frequent iterations. Don’t plan too far in the future; half of your plans will turn out inaccurate as time goes on.

NOTE: some say Scrum is part of Agile, while others disagree. After all, scrum focuses on specific methods while Agile proposes a mindset. Nevertheless, both Agile and Scrum stand for adapting to changes over time.

When assessing the difficulty of each task, one developer might score 1 while another 5 on a scale of 1 to 5 (where 1 is easy and 5 extremely difficult).

This, however, doesn’t mean that the developer who scored 1 is more experienced than the one who scored 5.

The guy who picked 1 might be aware of an approach that’s going to get the task done faster and easier.

The developer who picked 5, however, may be aware of a particular challenge that’s not easy to surpass.

Take the time to talk about each task’s difficulty for a couple of minutes; it can save you hours further down the line.

Conclusion

You gotta bear the following in mind: the goal of each scrum ceremony is to improve the development and sprint process.

The scrum team should reflect back on previous scrum artifacts, take notes, learn, and improve so it can produce better results next time it gets down to work.

The best thing you can always do is tailor your scrum process to the situation. Some things might work perfectly for others and bad for you.

Whatever scrum ceremony you’re attending, you always gotta ask the question “is this meeting worth it?”

Stay unparalleled,

P.S. It’d be sinful not to make a short blurb about Codegiant in a Codegiant article. I decided to save it for the last because I also hate it when I’m reading other articles peppered with a myriad of ads about their tools throughout.

So, if you are searching for a GitHub/GitLab alternative that offers a simply-designed issue tracker, git repositories, built-in CI/CD, and documentation tool, then feel free to check out Codegiant. That’s it. Enjoy!