February 2008

Monthly Archive

What Can Cause IT Projects to Fail?

Posted by on 24 Feb 2008 | Tagged as: Agile, Architecture, Leadership, Product Owner, Scrum, XP

Michael Krigsman provided an interesting variation of why blind dates so often fail and changed blind dates to project plans.

Reality versus Expectations

The interesting piece to me is the overlap area identified as “rare”.  I speak to many folks about their project expectations compared to plans and one phrase which comes up often is “well, it worked in [name of] project fairly close to plan”.  The somewhat rare success in planning up front seems to be a beacon for further use of particular project planning tactics.

I am not going to expand right now on this subject but I would like to leave this with something for us to ponder.  How many of your projects actually get even close to original plan expectations?  What methods in planning are actually adding to the success?  What types of projects are finding better success?  Let me know if you have any comments or wish to share your answers with the readers of this blog.

Product Owner “Tells” in Planning Poker

Posted by on 16 Feb 2008 | Tagged as: Agile, Leadership, Product Owner, Scrum, XP

Many of you may have heard of Planning Poker for estimating your Product Backlog items. Each team member gets their own set of cards with sizes identified on them in either story points (1, 2, 3, 5, 8, 13…) or t-shirt sizes (XS, S, M, L, XL…). The Product Owner tells us about one of their Product Backlog items they wish us to size in effort and complexity. The team members then choose what size they believe the item to be and once each team member has chosen their card they flip them around. The team must come to an informed consensus on the size of the item in order for the estimate to be final.

As an Agile Coach, I have been working with many teams for some time now on using Planning Poker for their estimation of Product Backlog items. Over time we have identified some “tells” that the Product Owner gives to team members to influence the estimation activity. The three most prevalent in my experience are the Jazz Hands, But-But, and most often used of them all Its Just.

Jazz Hands seem to come out when a Product Owner is describing a Product Backlog item they are excited about and hope will be able to make it into the next iteration. In order to show their excitement about the item their hands raise up near their chest and wave quickly back and forth. This physical display alerts the team members that this item is important to the Product Owner and we may be asked to implement this one quickly. If a team is not comfortable in looking beyond the Product Owner’s physical display to honestly estimate the cost of the item they may be influenced to size it small enough to fit into an iteration and risk not meeting their iteration commitments.

Once a team has come up with either an initial or secondary estimate show of cards the Product Owner may be caught off guard by the size this team has come up with. A common response from the Product Owner may start with “But, but…” which alerts the team that the cost is too high for the item in the Product Owner’s eyes. Although we have coached the Product Owner to respect the estimates made by the team they are unable to sit quietly by when such an event occurs. If a team is pressured by the Product Owner’s response to decrease the size during another round of estimating then the Product Owner will not get an honest cost and this items inclusion into an iteration may be fraught with risk.

Sometimes prior to the initial estimate by the team or directly following a But-But you may hear the notorious words Its Just. These two words usually indicate that the Product Backlog item in question has tremendous value and plenty of hidden work underneath it’s simple facade. The team should be wary of such phrases and enter the Planning Poker rounds with extreme caution. If the team members do not express the hidden work to our anxious Product Owner then the entire team may underestimate the item and get caught later in the software delivery life cycle with a humongous Its Just item on their hands. The team should take the time necessary to fully understand this item and its implications in the Planning Poker estimating discussions.

It is important for teams to own their estimates and take responsibility for their implications. It will not always be easy to give your estimate to the Product Owner. The Product Owner is looking for ways to maximize their ROI for the system under development. The team’s estimates are used as a check and balance to the Product Owner’s pursuits. There are times when the team hears one of the “tells” described above and then may engage the Product Owner in finding out a simpler acceptance criteria for the Product Backlog item in order to better meet their needs. Be careful not to ignore such “tells” though. It may lead to discontent for the Product Owner and the team later down the road.