âThe first edition of Extreme Programming Explained had a more abstract estimation model, in which stories cost one, two, or three "points". Larger stories had to be broken down before they could be planned. Once you started implementing stories, you quickly discovered how many points you typically accomplished in a week. I prefer to work with real time estimates now, making all communication as clear, direct, and transparent as possible.â
Kent used points, others used âideal daysâ, but the concept was the same. Points, or ideal days, were multiplied by some factor that converted the estimate into real days. I complained about this in my XP Overview article:
âOne thing that hurts XP in this area, in my opinion, is the use of âideal daysâ for estimates. To translate this to schedule time, the estimate is multiplied by a âfactorâ that is supposed to take into account interruptions, communication difficulties, and the like. The problem with this is that it buries the bottlenecks and their associated buffers in the individual estimates. According to critical chain theory, this is the worst thing to do! Another problem with this is that it effectively hides work inhibitors, rather than bringing them into full view of management to be dealt with on a daily basis (reference here is to the daily Scrum). And the worst thing about this is that it is not the language the business people speak. Business people want to know things in hours and days, not in craft-units or ideal days. Putting up artificial barriers to communication is contrary to XPâs value of communication.â
Nice to see that Kent is making things better in the second edition!
Previous Topic
