Planning Poker

Hello everybody, last time we clarified and re-estimated. There is time for another rule within Perfect Planning now.

This time it will be:

User Story estimation is done with Planning Poker in Story Points.

Ok, I would say there are three unknowns in one sentence. So, let’s look at them one by one.

User Story estimation

Each User Story represents some portion of work. By looking at the details, we can assume how much work we need to do to deliver the User Story and whether it is 100% clear what needs to be done.

But that is not all. The estimation of a User Story must include not only the amount of work (development and testing) to do, but also the complexity of the work and the risk or uncertainty in doing it. So, as you can see, several factors that can affect the time to finish one User Story.

Risk

The development needed for the particular User Story can be impacted by things such as another feature or function of the product, and things can get complicated. For example, while developing a User Story, you might have to touch existing functionality, which can affect other scenarios using that functionality. Or, you might have to use multiple components in order to deliver the work.

Complexity

For some User Stories, development is straightforward, and for others, it is not. Imagine that you are a house painter. You have to paint two rooms of exactly the same size. One of them has only a door; no windows, nothing else. The other room has three windows, a fireplace and obviously the door.

They are still the same size, but the first room is quite easy to paint. For the second room, you have to spend more time covering the windows, making sure that you paint the corners and edges properly and so on. Do you see the difference? That is the complexity of the task.

Planning Poker

Planning Poker is what we call a fun, playful way to estimate User Stories. If you have a collocated team (which is always preferred), you can use special cards made for Planning Poker.

They usually look like something like this.

As you can see, the cards contain numbers from the Fibonacci Sequence and some symbols. The symbols are there because sometimes we really have no idea (?) what to do with the User Story or we need a break ☕.

Each member of the team receives a set of cards, and once the Product Owner explains what the User Story is about, the team has a chance to discuss the User Story and everything is clear, they estimate the amount of work.

They are given around a minute to think about the User Story’s needs and then they show the card from the deck with the number that, according to them, represents the effort required to deliver the User Story.

Everyone shows their cards at the same time. This is important so that no one is influenced by the others and each voice is heard.

If there is a situation in which there are varying cards revealed, such as most people put down a 5 but a few put down a 3 or an 8, people that vary from the most common value are asked to explain why. They may see some potential issues that others do not or they may know a shortcut to decrease the effort. After they explain their point of view and the team has time to consider their comments, estimation happens again. In my experience, it is rare that the same situation—a big range of numbers—happens twice in a row for the same User Story.

If you do not have a collocated team, there are many online planning poker options; just find one that suits you best. Or, try to add a planning poker feature to the tool in which you organize your work, such as Jira, Trello or Targetprocess.

 

And the Story Points?

We already published an article about these, but let’s review.

As I mentioned above, we use the Fibonacci Sequence for estimation. Why? Because by using such a sequence, we can reflect size, complexity and risk better.

Let’s say that we estimate a User Story as one Story Point. The User Story that is estimated as two Story Points has to be twice as big because we are giving a relative value to the User Story. But, what our team thinks is one Story Point could be three Story Points for another team. This means that in our case, a two-Story-Point User Story has to be six Story Points for them. Does that make sense?

Some people fall into the trap of man days. I do understand why, but Story Points really do not represent only the time you spend developing the User Story. Don’t forget that testing is also a part of development and it has to be considered when we think about the size of a User Story.

 

I hope that is all a bit clearer now. We will be back with another rules soon. Thank you for reading.

Have courage and be kind.

You may also like:

Modes of Planning (Part IV)

If you read our last article, you might think that it had to have been the last planning mode. What else is there if ad…

Modes of Planning (Part III)

As we promised last time, here we go with another Planning mode. This time it is going to be about ad hoc Planning. This…

Modes of Planning (Part II)

The article we published last time was dedicated to the basic planning mode, Capacity Chosen. In this article we would like to explain the second…

Comments