Planning Poker

How to do Story Point Sizing with Planning Poker?

Story point estimation is all about relative sizing. In order to compare the amount of work of one story to another, we need to identify a base story in order to define the base story point size.

It will be important to know that story points follow fibonacci series and have 0, ½, 1, 2, 3, 5, 8, 20, 40, 100 numbers. So when we talk about a base story, we essentially are talking about a one story point story.

A Base User Story

A base user story is the smallest possible piece of work that delivers business value to the user.

As an example – a team may decide that on a search screen, adding one additional field may be the smallest piece of work for them.

Who all should Participate in Story Point Sizing Activity?

by ShriKant Vashishtha Leave a Comment

There are folks who may be moving from waterfall to agile approach.

They in general divide the estimates in terms of development estimates and testing estimates. These estimates are separately done by the representatives of developers and testers. These representatives are either not part of the team or may not be doing that work.

In Agile teams, the story point sizing activity is done by the whole development team.

Just to reiterate again, all cross-functional team-members participate in the sizing activity. Also, there are no separate story points for development and testing activities which could potentially enable the team members to estimate them separately and combine them together to come up with the resultant size of a story.

What is a Story Point?

by ShriKant Vashishtha 1 Comment

Story point is a unit of measure of estimation for the overall size of the work that will be required to fully implement a user story.

Story point has no direct relation with time even though people may get tempted to map it with time in order to get an hourly estimate to complete a user story.

To understand story point concept better, it’ll help to take an analogy with distance.

All About Story Points and Agile Estimation Series

by ShriKant Vashishtha 1 Comment

Lots of Scrum teams have been using story points and planning poker for relative sizing.

However, this is one of the concepts like pointers in C, which troubles most of the teams and they all have their own interpretations on the subject. Lots of material has been written. However it becomes difficult to join all the dots together for any team-member to digest at one place. This series of posts is an attempt to simplify learning and make the concept as clear as possible.

Some of the posts were written in the past and some I am writing now in order to have completeness around the subject. This list will keep getting updated as I write new posts on the subject.

Planning Poker is NOT about Agile Estimation!

by ShriKant Vashishtha 3 Comments

One of the popular mechanisms to estimate story points as a team is planning poker exercise.

It’s an awesome technique but it may become a challenge for some teams. For instance, a team estimates story points separately as developers and testers. Later, they add up those points to arrive at resultant estimates.

Some teams get into endless discussions to ascertain if the estimate should have been 2 or 3, 5 or 8 or maybe 7.

It looks like, the primary goal of planning poker exercise is to arrive at the correct estimate.

But that’s not the point!