When it comes to Scrum, Scrum Poker is an important tool to do the process. A project consists of Sprints and Sprints are built up of events. The role which each of these events plays and the way in which they take place can differ considerably based on factors like the the product that is being developed, the experience of the people involved in the project, and the preferences of the team members themselves. In general though, in a traditional Scrum project, a Sprint contains at least four major events, namely Scrum planning (also known as Sprint planning, here is Scrum Poker often used), , the Daily Scrum, the Sprint Review,and the Sprint Retrospective.
Besides the roles and the events that are relevant to Scrum-based projects, the so-called artefacts also represent a key element of the Scrum framework. Usually, there are three artefacts that present in every Scrum team, namely a Product Backlog, a Sprint Backlog, and a type of backlog that defines a “finished” part for you. An artefact in a Scrum environment is a type of tool that teams can use to solve complex problems together. Considering the particular role and importance of the Product Backlog to the correct functioning of a Scrum team, we also dedicated a separate piece to this artefact
As you probably know by now, Scrum is an agile methodology to help plan, manage, and optimise product development cycles by cutting them up in a series of fixed-length iterations. As we wrote before, both earlier in this article and in separate articles in this Scrum series, a Scrum production cycle or Sprint consists of at least four main events: Sprint planning, Daily Scrums, the Sprints themselves, and Sprint Retrospectives. In our series, we have also covered the Sprint Reviews, which take place after the Sprint ends and before the Sprint Retrospective is held. In order to help Scrum teams perform these events with ease and to chase the highest possible product value for the end customer in the most efficient manner possible, Scrum teams can make use of several sets of tools that were especially designed for use in Agile projects. Our previous three articles were on Scrum Boards, Kanban Boards, and burndown charts, and this piece is on the final tool we will covering for this series, namely Scrum poker.
Scrum pokers differs considerably from the other tools we have covered in this series of articles, in the sense that it is more of a technique than it is a tool. Scrum poker (which is often referred to as planning poker as well) is actually a gamified technique based on consensus that is used for estimating. When relating this to Scrum and (software) development projects specifically, this technique is mostly used to estimate effort or relative size of development goals. We can understand if this still sounds a bit vague, especially to those people with little or no experience with Scrum-based projects, so we will take this opportunity to take a deeper look at what Scrum poker is, how it works exactly, and what its main benefits are.
What is Scrum poker exactly and how does it work?
When planning for a project, either a big or a small one, there are always three broad elements you need to know, namely what the tasks are, how big these tasks are and how long they are going to take to complete, and what the priorities are. In case of most Agile projects, the tasks are largely created by the business and this business usually also decides on task prioritisation. The size of each task is something that the involved development team is more qualified to determine, though. This team is, after all, working on similar matters day in, day out, and this is where planning poker comes in.
Planning poker, or Scrum poker, is a collaborative and relatively recent planning tool that was first defined by James Grenning in 2002, and made popular in the following years by Mike Cohn, one of the contributors to the Scrum software development method, one of the founders of the Scrum Alliance, and the founder of Mountain Goat Software. The tool consists of different cards and is literally played like a common poker game, and the clearest way to explain how this can lead to more effective planning is by describing a mock round of Scrum poker.
How is a round of Scrum poker played?
Scrum poker is actually not very hard to play at all, as it is based on a few simple rules. It is played with a deck of cards with different values (which generally are 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, and ?), with the ? to be used when a team member has no idea of what to estimate. Remember that Scrum poker is used to estimate relative task size, so the zero indicates that an item is already completed or too small to assign a value to. From there onwards, the bigger the value on the card, the bigger the estimated size of the item in question.
For the sake of this example, we are using a Scrum team with a formally appointed Product Owner who starts off each round and a Scrum Master who guides the game. To start a round of Scrum poker, the Product Owner picks a task and reads it out loud in order for the development team to discuss it. Like this, every team member receives the same information and the subsequent open discussion makes sure that the whole team knows everything about what they are being asked to estimate. These items are usually User Stories, like “The User logs in to his personal profile”.
Out of the previously mentioned Scrum poker cards, each team member picks a card with the value he or she believes represents the size of the development item in front of them and places this card face-down on the table. Only once each team member has picked a card, and thus a value, all cards are revealed at the same time. This might sound a bit unnecessary, but it helps to assure that no team member's decision is influenced by the decision of another team member.
In case there is no immediate consensus on the item, the Scrum Master asks the people with the lowest and the highest value estimate to explain the reasoning behind their picks. Based on these insights, a new round of Scrum poker is then initiated to see if a consensus will be reached. In theory, this process can be repeated an infinite number of times until perfect consensus has been achieved, but generally the team will come to an agreement after a few rounds.
The result of such a round of Scrum poker as described above is an estimate of the size of each item selected by the Product Owner. All of these values together will provide the Scrum team in question with an idea of the relative size of each task. Whether this idea is good or bad largely depends on the quality of the estimates and therefore the quality of the Scrum poker process.
What are the benefits of Scrum poker?
So Scrum poker might sound a bit complex at first, but it just takes a few minutes to understand the basics. After that, practice makes perfect, as the saying goes. A question that still remains though, is to what extent Scrum poker really benefits a Scrum team. Like any other tool, it is not a perfect tool, but correct usage of the concept can have a very positive effect on a development team.
Scrum poker provokes discussion
Though time-consuming at times (which is one of the disadvantages of Scrum poker), Scrum poker is an excellent way to get a Scrum team to discussing. In the end, the whole concept revolves around the idea of discussing in a free and open manner until consensus is reached. One of the key tasks of the Scrum Master is to guide these discussions and to make sure that they stay on topic at all times in order to avoid wasting time.
Scrum poker can provide important relativity
Many projects succeed or fail as a result of the estimates on which they were based, which underlines the importance of making good estimates. You don't want to start building a house on a wobbly foundation, after all. One of the main benefits of Scrum poker is that it allows team members to estimate tasks relative to one another. They may not be in a position to know exactly how long something will take to do, but it should always be easier to estimate whether it would take more effort or less effort than a similar task that they have already completed.
Scrum poker creates a general sense of contribution
In a Scrum team, like in any other team, there will always be more extroverted and less extroverted people. That's completely fine, but this can lead to situations in which certain team members contribute less to the team's decisions, or at least, that they feel like this. Few things are more demotivating than feeling like you have nothing to contribute to the project, so it is important for each team member to feel involved and valuable. By requiring active participation and estimation from everyone in the team, Scrum poker can help to achieve this.