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 some terms, repeatedly, without recognizing them.
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 making you more prepared for interviews and your first meetings. Or in case you are feeling shy, which by all means, you should not. After all, as one of my professors used to say:
There’s no such thing as a stupid question! Only stupid answers!
Just a heads up, this post is meant to be a simplistic approach to Scrum and some of its basic concepts. It is not a post that is meant to be a preparation for the Scrum certificate nor one for scientifically describing what is Scrum. It’s just a friendly and practical intro to some of Scrum’s concepts and my basic goal here is to help you become more prepared by having all the information you need for working with these concepts. Ok, you’ve been warned, let’s start our exploration…
Scrum terminology
Scrum is a framework used for managing projects. It has nothing to do with the way you write code and implement features. It is often used in software development but can also apply to various 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.
Some terminology about Scrum’s tools:
(I dislike terminologies too, for now just think of the following terms as defining, a few words, so that we can both understand the same things…)
Sprint
A sprint is a pre-determined period of 2–4 weeks, as 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 backlog is a list of tasks and features that are waiting to be evaluated, prioritized, and when it is decided, added in a sprint. You could think about it as a to-do list.
Roadmap
A roadmap is a plan which includes all high-level goals and milestones for a product. You could think of it as a combination of which features a company wants to implement and when they plan to. By looking at a roadmap, one should have a clear overview of the path defined by the product team regarding the product’s vision.
Daily Scrum (a.k.a Standup)
Is 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? Because 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 and poker
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 new sprint.
Although guidelines on what is discussed during such meetings vary from team to team, some common discussion topics are:
Which tasks from the backlog should be implemented 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.
🕵 Acceptance criteria is a list of characteristics a feature should have to be considered successfully implemented.
🕵 Bottleneck, is a term usually used when we refer to an issue that is blocking more than a few, other processes.
During your meeting, and before the product manager decides to start 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 point, which represents the difficulty of the implementation of a feature. The larger the number, the greater the difficulty. There’s also a coffee and a question mark card. A coffee card is used when a member of the team needs a small break and the question mark is used when a member is missing information to decide on an item’s 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
A feature is selected from the ones decided to be added 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 from step 1. This process is repeated until all sprint items have poker scores.
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 difficult 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
I remember 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 member of the team 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?
What was 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?
The reason I like it is that 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!
Till next time. 🤓
Top comments (0)