Agile PM Process Grid–3.8 Estimation and 3.9 Sizing

In John Stenbeck’s book “PMI-ACP and Certified Scrum Professional Exam Prep and Desk Reference”, he creates an “agile project management process grid” which describes 87 processes used in agile project management. These processes are divided into five process groups (Initiate, Plan, Iterate, Control, and Close), which are analogous to the five process groups in traditional project management, and seven knowledge areas which can be mapped, more or less, onto the ten knowledge areas in traditional project management.

Today’s post discusses both the process 3.7 Estimation and process 3.8 Sizing.   In previous posts I discussed the principles behind these processes,  and in the current post, I want to reiterate John Stenbeck’s explanation of how they address three significant risks related to the estimation process in general.    Planning poker (process 3.11) and the use of Fibonacci numbers were addressed in the last post.

  1. Any group faces the pressure to conform to the group’s worldview; this process is sometimes referred to as group think.   One of the ways Japanese avoid this process is by having the youngest person state their opinion first.    Japanese society respects seniority to a greater degree than American society, in general, and they recognize that if the more senior members of the team were to state their opinion first, there would be a lot of pressure for the younger person to conform to the opinion just stated by their superiors.   This pressure exists in American society, as well, however, although not to such great extent.    A way to reduce the pressure is to have each team member reveal simultaneously his or her vote regarding what size a particular user story should be.   In this way, no one is pressured beforehand to conform to any opinion but their own.
  2. Any group faces the pressure to do things the way they have always been done.    A person who argues from this standpoint is said to be anchoring his or her opinion.   The problem with an anchor, of course, is that a boat cannot move anywhere while the anchor is deployed.   So after a person gives a vote for the size of a particular user story, he or she is expected to justify that decision within the context of the project itself and not to justify it by reference to previous projects.
  3. Any group faces the pressure to defer to experts, those that have experience within a certain field of expertise.   However, many of the biggest breakthroughs come from non-experts because they are viewing the situation with fresh eyes.    The so-called experts may have just absorbed the “received wisdom” which is based on assumptions that may end up not being true after all.   Thus each member votes on the size of every story, and not just those within their particular field of expertise.   This is the way to get ideas that challenge the status quo.
The Planning Poker process 3.11, which asks a team of people to size user stories in a way that allows each team member to voice his or her opinion, is a powerful process.   If you need experts, one way to duplicate the power of this estimating method is to use a process called 3.10 Wideband Delphi, which is the subject of the next process.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: