One of the techniques that Agile teams use in grooming or planning sessions is Planning Poker. The game is very simple, and also a very nice instrument to provoke discussions and enhance the quality of the planning meeting. For those of you who are not familiar with it, here is an explanation of some key concepts.
First, what are story points and t-shirt sizes?
Before you play, choose the unit of measure you want to use for your estimates. Typically, teams estimate in story points or in T-shirt sizes. Both of these units represent the understanding about complexity, risk and effort to implement a user story or an epic.
Many teams face difficulties to understand the concept initially, especially when using story points. It is indeed tricky. We are so used to planning in hours and days, that we easily start putting an equality sign between a story point and an hour. This is, first of all, wrong and second, completely ruins the idea of the story point.
When we plan in story points we are not interested in how much time we think it will take to get this story finished. We are rather focusing on what activities might be required to complete it and how complex they are from the perspective of our current knowledge as a team. Then we put some estimate to the story, which is relative to a baseline story that we have defined previously.
What is a baseline story?
The baseline story is the reference that the team will pick in order to compare new stories against it in terms of complexity and amount of effort.
It is very important for the team to understand well what activities the baseline story contains. A good approach to do it is:
Take a small story that you implemented before or one that you understand very well
Make sure that everybody on the team has the same understanding
Finally, decide how much story points or which t-shirt size you will allocate to this story. It will later serve you as a guidance to estimate the others.
The benefits of playing
Estimations can be tedious, especially when a lot is unknown (familiar case, right?). Many teams are not super excited about it, also because estimations are often confused with commitments.
Using a game and relative points instead of man days or hours takes some of this pressure off. In addition, trying to assess and quantify levels of complexity triggers meaningful discussions in the teams. It is a great way to reveal information, biases, and assumptions, so that we can address them.
Raising awareness and collective knowledge is from my perspective one of the most valuable outcomes from the exercise.
The tricky part about estimation in relative sizes
Teams often use story points to measure team velocity. It is the amount of story points that the team produces in a sprint. Be careful with that though – do not compare velocity across teams! Remember that two different teams might estimate the same story differently. It is because the definition of the story point is specific to the team. Moreover, each team will have different experience and skill set and assess complexity differently.
For example, imagine that our team has the task to paint our living room. We estimate the effort and complexity of painting a wall without windows to be 1 story point. Next, we estimate painting a wall with the same size but with a window in the middle to 0.5 story points if we have special tools to protect the window and some experience with painting such walls. But another team without the tools and experience might estimate the same work to 2 story points as more complex from their perspective.
Teams new to Agile and the concept of estimations in story points might adopt T-shirt sizes easier, because they are less difficult to confuse with hours.
In the next blog post, we’ll discuss how the Planning Poker game is played, along with some alternative practices that can be used.