Friday, September 19, 2008

Problem I faced with Planning Poker



I copied this cartoon from www.implementingscrum.com.. Im a cartoon freek.. and thrilled to see SCRUM in cartoons...:-)

We played planning Poker for the 1st time and following are the problems I faced.. I will find the answers for these questions from experts and post them here later..

1. When Moderator reads 1 story we kept playing Poker and came out of an estimation to that specific story., But when we went through the PB more and more., team wanted to revise the previous story estimates again as its a comparative thing., How do you handle this situation?
Do you get the team to analyze the PB before coming to Planning poker so they will be more or less accurate with their comparative guess with other user stories in the rest of the product backlog?

2.There was one user story which we had to purchase some device for that. Scrum master ask where do we do the procurement management, planning , Cost estimation etc, Will SCRUM has some guidelines for procurement management for the project.

3. Customer who acted as the product owner didnt have answers for some of the questions.. there were situations such as I need to check with my infrastructure guys.. I need to ask my BI manager etc. How do you tackle that situation?

4. for certain stories we felt that we need the use cases or further analysis before thinking of their weight. ..

5. Looking at from the Project Office I saw many team for many projects they had different type of assessments. As an Example., same story "User needs to log in to the site and fill the registration form" was rated by the Team A as 5 and Team B as 20.. so how do I compare and see each team performance from the top when I look at my teams product burn down charts?

2 comments:

worm-p on 1:54 PM said...

Like you said no process or framework is god-given and it seems to me that the key to many of these issues will lay within the proper preparations made forehand as no one can design e.g. a financial system over a poker meeting, but having said that and given that the proper analysis has been done, the poker situation will be able to bring a sound and critical discussion to many of the issues faced within any project.

And not least – to bring up many of the issues typically overlooked at this stage in a traditional development environment (and left to the developers “to figure out” as per when they run into that particular wall..). This would probably often result in a conflict over a “CR” of some sort, which most clients seem to hate even more than the bill it will carry as a result.

An absolute pre-requisite to any successful software project will always be that the customer knows what he’s looking for in the end, and have done his part as to be able to answer the most important issues. A poker meeting should probably not be the venue for “inventing the wheel” but rather to figure out how to make it rolling.

A degree of further research may be required if the situation arises where the product owner doesn’t have the answer to main questions, and that may actually mean that it is too soon to play the game all together..?

Anonymous said...

Im honored that you've visited my blog. But in the same time I will make sure that I will be much more careful about what I post here :-)

Yes Planning Poker is not a session to design the product. There are lots of techniques such as creating mind maps which really help the product owner to gather details about the product requirement before the meeting by gathering with his own business users. However there is a chance that the product owner won’t be able to answer all the questions.. So some times I’ve seen some teams have 2 product backlog planning meeting.. Before and After.. Yes there are many other alternatives we can think of as this is a “Frame work” However still Im in discussion with many SCRUM practitioners about tips and techniques they use and its very interesting..

Thank you so much for your interest on this topic and the knowledge you shared.

Be a PMP
 

PROJECTIZED. Copyright 2008 All Rights Reserved Revolution Two Church theme by Brian Gardner Converted into Blogger Template by Bloganol dot com