When I got my first job as a web developer, I was over the moon! Part of my everyday work was to join various meetings. In many of them, I heard unfamiliar terms about scrum repeatedly without recognizing them. Inevitably, this sparked my curiosity, leading me to research what is scrum and its associated jargon.
Don’t get me wrong, I could, of course, ask, I could, and I did, when I didn’t feel shy to do so (yeah, I am that kind of person… 🤷♂).
After learning these terms, though, I wanted to share them with you. They might help you by preparing you for interviews, for your first meetings, or if you are feeling a bit shy (though you really shouldn’t be). After all, as one of my professors used to say:
There’s no such thing as a stupid question! Only stupid answers!
Heads up! This post is meant to be a simplistic approach to Scrum, think about it as a friendly and practical introduction to some of Scrum’s concepts. My basic goal here is to help you become more prepared by having all the information you need when working with these concepts.
Ok, you’ve been warned, let’s start our exploration…
Scrum terminology
Scrum is a framework, a set of “rules” and tools, used for managing projects. It has nothing to do with the way you write code and implement features. Companies use it for managing software development phases but it may also apply to other types of projects.
Scrum has a set of meetings, principles, and tools that were created to help teams achieve their goals faster and more efficiently.
Let’s check some terminology about Scrum’s tools:
(I dislike terminologies too! It’s just that we need to define a few words so that we can both be on the same page…)
Sprint
A sprint is a pre-determined period of 2–4 weeks (duration is agreed upon by the team), during which the team decides to achieve specific objectives. In a team of developers, these objectives would consist of implementing some features.
Backlog
A list of tasks and features that the team needs to evaluate, prioritize, and add in a sprint. You could think about it as a to-do list.
Roadmap
A roadmap is a plan that includes all high-level goals and milestones for a product. Picture it as a combination of the desired features the team intends to implement along with a carefully crafted timeline. By looking at a roadmap, one should have a clear overview of the path that was defined by the product team regarding the product’s vision.
Daily Scrum (a.k.a Standup)
A meeting that is held on a daily basis, in which each developer answers the following questions:
- What did you do yesterday?
- What will you be working on today?
- Is there anything blocking your work?
Why is it called a standup? Usually, when this meeting takes place, the team creates a circle in which every member is standing. The reason behind standing up is to finish quickly your daily report and not spend more time than needed.
Now that we know a bit more about Scrum let’s see what is a Sprint planning meeting and how we play Scrum poker.
Sprint planning
Before the start of a sprint, the development team and members of the product team will hold a meeting called the Sprint Planning meeting or simply Planning.
The goal of this meeting is to decide, usually based on priorities, which features will be implemented by the team in the upcoming sprint.
Although guidelines on what you would discuss during such meetings vary from team to team, some common discussion topics are:
- Which tasks from the backlog should you, as a team, implement in the new sprint?
- Define the team’s capacity. By capacity, we mean how much work each team member can achieve during the next sprint
- Review any new feature specifications and acceptance criteria
- Define potential bottlenecks
- Assign tasks/features to a developer based on their capacity
Each planning is unique and may vary from team to team. So take what I describe here with a grain of salt.
Acceptance criteria is a list of characteristics a feature should have to be considered successfully implemented.
Bottleneck is a term used when we refer to an issue that is blocking other processes.
Scrum poker
During your sprint planning, and before the product manager decides to finalize it by starting the new sprint, you could hear your team members asking for poker time!
Yeah not that kind of poker, although a good poker face is always an asset! To play Scrum poker, first of all, you will need a special deck of cards, one example is seen in the image below:
Each card has a score, which represents the difficulty of the implementation of a feature. The larger the number, the greater the difficulty.
Playing poker isn’t hard at all… Scrum poker I mean. How is it played you ask? Let’s have a quick glimpse:
Preparation
Every team member gets their own cards or uses scrum poker mobile apps, instead of cards, if they fancy electronic cards. They all sit together or open cameras if the team is remote.
Playing poker
One member of your team selects a feature from the ones you have decided to add in the new sprint.
Every member evaluates the feature by deciding on its implementation difficulty and selecting the respective card. This process is done without members sharing their thoughts or showing the card to each other. Not yet at least.
One member (usually from inside the team) starts a countdown, of a few seconds.
When the countdown ends all members show each other the scoring card they‘ve selected, for the sprint item, under evaluation.
If all scores are the same (yeap it can happen) this score gets assigned to the sprint item. If there are significant differences between cards, then, whoever has a card that deviates from the team’s average shares their thoughts on the reason for their selection.
E.g if the average amount of cards shown is 13 and one member has selected a card with the number 40, it would be nice to explain the reason. This way the team might find out if something got ignored by mistake about the item’s implementation, from the other members of the team. If the team still feels they need to stay at 13 then the score is assigned to the card, otherwise, they change it to a new one.
Since the evaluation of the feature has finished, The next sprint item is selected and the loop starts again. This process is repeated until all sprint items have poker scores.
You may also like 🎬
Why do we play poker?
Ok, we played poker, but why? What does this score represent for each card? This score is just a difficulty level, it means something is more difficult compared to something else. It has nothing to do with how many hours, or days it will take for a feature to be deployed.
But why do we care to score, based on how difficult something is?
Let’s say you have a team that has worked for 10 sprints, and in each sprint, the team has developed, features of, on average, 65 points. By knowing this, a product manager will be able to identify how much their team can deliver and how fast that could happen.
Now, wait a minute there… I used the “how much” word, right? And we said that score has nothing to do with time…
Well yeah, but in the end, it’s a metric, which will inevitably get used by the product team when a roadmap is created. It will be used to answer how soon some features may be deployed and when some goals from the product team could be reached.
I believe now you are ready to play some poker when requested by your team! Just don’t forget your hat and sunglasses! 🤭
Hint
If you have just been onboarded on your team, it may be not easy to evaluate a feature, since you may know nothing about the codebase… It makes sense, and your team knows that, so don’t feel bad about it, give it your best guess and you’ll be just fine!
Retros
So your sprint has finished, you gave it your best and now it’s time for confession, the retro meeting!
The first time I got in a retro meeting, my manager, told me “Would you like to start?” and I was like… “Sure… what should I say?” 😇
Retros, or Sprint retrospectives, are the best meetings of the Scrum framework! At least from my point of view. A retro meeting is set at the end of a sprint and is a powerful tool that teams use to get information about the issues they faced during the sprint.
During the retro, each team member reflects on what was good or bad during their sprint. As a guideline, usually, some of the questions you would see getting answered would be:
- What went well during the sprint?
- Was something problematic?
- What could be improved in the next sprint?
- What can the team do to better support each other?
- How can the team improve its performance?
I like it because it’s a great opportunity to share your thoughts/feelings and by doing so, bond with your team. It might feel difficult to do so at your first gatherings, but after a while, you’ll love it! I’m sure!
It’s group therapy if you think about it 😇 and a great way to finish your sprint/week! Believe me, if you learn how to master this meeting, you will be able to help your team and also improve your workflow! Don’t be shy, you got this!
