Posts tagged ‘planning poker’

June 22, 2012

Agile Estimating over a coffee and 3 glasses of water

by Sampath Prahalad

Joseph Flahiff of Whitewater Projects explains about Agile estimating in layman terms by using 3 glasses of water. Ignore the background noise. This really is a nice video. Keep them coming Joseph.

read more »

April 23, 2012

Scrum rituals, summarized…

by Sampath Prahalad


Happens on

What gets done



Sprint planning meeting

First day of the Sprint

  • The capacity of the team for the Sprint is determined.
  • User stories for the sprint are presented by the PM, and agreed upon between the team and the PM based on team capacity
  • The team then breaks the User stories into tasks and assigns the tasks to themselves.

Sprint planning meeting is complete only when both the above are Completed

  • If there is an investigative User story, a specific time period (maybe a week) is alloted to that with the aim ofcoming up with the next steps.
Once planned, the contents of the Sprint are to remain constant for the duration of the Sprint. Any recurring activities like Production Support can be put in as a separate user story or their effort need not be tracked as part of the Development sprint.


Daily Scrum meeting

Every day of the Sprint

3 questions to be answered by the team.

  • What did you do yesterday?
  • What will you do today?
  • What impediments do you face?
This is not for the managers but for each other. If it is becoming a status meeting, the manager can be asked not to participate


Sprint Review / Demo

Last day of the Sprint

An informal demo of what was achieved by the team to the Product manager and other stakeholders in the Sprint. Anyone in the Delivery team can give the demo. The Sprint review focuses on the product and not the Process

Only User stories that are developed, tested and ready to deploy are ones that classify as Done.


Sprint Retrospective

Last day of the Sprint

The team (minus the managers) reflects on what went well during the Sprint and what processes can be changed for the better.

Continuous process improvement.

The Sprint Retrospective focuses on improving the Process and not the Product.


User story Sizing (Optional but recommended)

Once every 2 (or 3) weeks

Sizing of the user stories in the prioritized backlog list. The PM and team go through the user stories, play the planning poker game and assign story points to the user stories. Pace: 6-10 user stories per hour. The Intention is to have a backlog that is prioritized and well sized at any point of time so that the PM has enough information ahead of Sprint planning to identify the user stories that provide the most business value.
March 3, 2011

When is the perfect time to play Planning Poker?

by Sampath Prahalad

Question: When is the right time to estimate the User stories in the Product backlog?

Answer: User story estimations are usually taken up during Sprint planning. To know the planning poker process involved, refer to ‘Estimating using Planning Poker’. The good thing of doing the estimations just at the beginning of the Sprint is that the Product Owner knows exactly which user story is urgent and important to be taken up at that point of time. However, the flip side is that there is pressure (and good amount of monotony) on the delivery team to complete the estimation and then perform task break up and task assignments within the small planning window. There is a tendency of the planning window becoming big and eating into the actual implementation time of the Sprint.

So then, what is the solution to this?

The solution is to make the User story estimation meeting a short recurring one and not tie it to the Sprint planning session.

Here is how it works.

read more »

January 12, 2011

Estimation using Planning Poker

by Sampath Prahalad

Now imagine that each team member is holding a deck of cards, containing the following cards:


Let’s do the estimation. The product owner says:


Before we continue, a small note on the numbers.

1: Small UI enhancement or bug fix. Easy to develop, easy to test.

2: Adding a small change/enhancement to existing functionality

3: A slightly bigger change to existing functionality or a fairly simple module to develop and test

5: A feature or enhancement that touches few other modules, We understand it well. It is complex. Testing impact is significant.

8: A feature or enhancement. We have some understanding, Some investigation is needed, it is quite complex and will touch few modules. Very significant testing impact.

13: Pretty complex. Might need more than a Sprint to accomplish by 1 person. Better to split into smaller User stories.

20: I don’t even know what you are talking about. Very complex, Needs good amount of investigation. Let us revisit it once the PM provides more clarity. Cannot estimate at this point of time.

The team starts thinking about how long the story will take.


All participants have to present a card, face down, containing their estimate. Everybody has to present a card, so Mr D and E wake up. Mr D admits that he was sleeping and asks what the story is about. It’s harder to slack off when doing estimates this way :o)

When they are done, all cards are turned over simultaneously, revealing everyone’s estimates.


Whoops! Big divergence here. The team, in particular Mr A and Mrs C, need to discuss this story and why their estimates are so wildly different. After some discussion, Mr A realizes that he has forgotten some important tasks that need to be included in the story. Mrs C realizes that, with the design that Mr A presented, the story might be smaller than 20.

After the discussion (3 minutes in total) they do another estimation round for that same story.


Convergence! OK, not complete convergence. But they agree that an estimate of 5 should be close enough. Next story.

%d bloggers like this: