Agile... Creating Story Points and Telling Lies

One of the activities taken in an Agile software development effort is assigning some form of identification to determine the relative size of the story in the product backlog.  There are a number of ways that the relative size could be specified.  T-Shirt sizes (XL / L / M / S).  Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, etc…).   Effort in days or hours.

It doesn’t really matter what metric you pick to assign this relative unit to the story - but there are some guiding principles that should be followed and some understanding of the nature of the people doing the estimates.

• Define a Baseline - Since the points assigned are relative sizes it is vital that everyone can answer the question “relative to what”.  It is a trivial task to compare two stories to each other.  However, comparing tens or hundreds of stories requires that everything is compared to the same thing.  Otherwise the relative comparison will fall short.
• Be consistent - Let’s say “Story Foo” has 5 story points assigned to it because compared to the baseline it is deemed 8 times more difficult than the baseline.  When “Story Bar” is being estimated it should also be compared to the baseline.  However, it should ALSO be compared to “Story Foo”.  Too often “Bar” gets 5 points compared to the baseline even when the team believes it is twice as difficult as “Foo”.
• Timebox the Activity - Let’s face it - people lose focus easily.  The estimating activity is one where the team can get into a “bad” rhythm.  Instead of really thinking about “Foo” and “Bar” they respond with the same estimate because they appear the same even when there can be significant differences.  About a 30 minute timebox is appropriate.  
• Don’t Estimate Everything - First of all, don’t estimate epics.  You don’t know enough about the epic to be anywhere near right.  Secondly, think hard about how much in the future is required to be story-pointed.
• People Translate - Whether they say this out loud or not - people are translating from “duration” to “points” when giving their estimates.

How is all this related to telling lies?  I like to think of estimating software development in terms of telling lies.  There is an amazing phenomenon that occurs when asking a developer how long an activity will take.  For some reason there is magic about answering “2 weeks”.  When I was the project manager for a very large pre-agile project I would ask how long something would take.  Of course the answer was “2 weeks”.  OK, fine… about 6 days later I would ask how things were progressing and of course there were problems that were going to delay the completion of the task.  When asked how long to work through the problems and finish the task, the answer… you guessed it… “2 weeks”.

There is ONE AND ONLY ONE accurate answer to the “how long” question.  That answer is “I don’t know” - everything else is a lie.  I said this in a training class once and was met with “that is a very strong word - it isn’t a lie, it is the best estimate I have at the time”.  My question to this person was “Define the word ‘lie’” which she defined as “telling someone something that you know isn’t true”.  Need I say more?  Telling me “2 weeks” is telling me something that you know isn’t true”.

Bottom line - Story points, estimates, lies… everyone related to the project needs to understand that by the very nature of the activity, the result will not be very accurate.  In fact, when the task is supposed to start, the size of the task, and the level of understanding of the story are all factors in how big the lie is.  A small, clear task starting now will have a fairly accurate estimate.  A large, nebulous task starting in 4 months - well, that’s a whopper.  It will probably take 2 weeks.

Tools

Given that I like Rich Internet Applications (both to write and to use), here is a list of tools that I really like. I need to say though, that as much as I like these tools, I can't seem to ever break away from the habit of using my desktop tools instead. I don't necessarily find the desktop tools any better (usually), but when I want to write a document I reach for Word first. Is that an indication of the ultimate future of RIA's? When even a person that believes fully in the technology doesn't make it a habit to use them?

This list isn't just RIA applications though...

Gliffy - drawing tool

SlideRocket - Presentations (although these people made me mad... so I probably won't use it - it is still pretty nice technology)

Buzzword - Word Processing... now all bundled together under Acrobat which also has presentations and spreadsheet functions

YUML - Create UML diagrams

Files2U - Send large files to others by uploading to this service - very nice

Design Patterns: Decorator and Proxy

Continuing the search to find just the right way to describe the difference between the Proxy and the Decorator patterns. The best one I've found so far is here. To summarize... the Proxy pattern establishes the target object at compile time while the Decorator pattern establishes the target at run time. This allows the Decorator pattern to also be nested many levels as the target object (being either the original target or a decorated target) is passed in to the decorator as a parameter. The Proxy would be a single level deep as the target is instantiated inside the proxy itself.

Design Patterns: Decorator vs Chain of Responsibility

I am teaching a class this weekend on Design Patterns and the students are recognizing that many of the patterns start to look alike. Since the patterns rely on good OO principles like coding to the interface, then this is true.

However, someone was asking for a more detailed description of the differences between the Chain of Responsibility and Decorator patterns. I gave them my take on it but decided to do a little research on the topic.

Admittedly, this was very little research and I still believe my original answer holds true...

I believe that the biggest difference is that the client should have no idea that a Decorator is being used as opposed to the target object. However, they certainly know if they are using a Chain of Responsibility because the target object is passed along the chain.

I don't think that the primary difference is that the chain can be stopped at any point in the Chain of Responsibility structure while it must proceed to the target object in the Decorator. Would that mean that any Decorator "wrapper" that does not call the next Decorator (or Target) is no longer a Decorator? What if I'm decorating an object to perform some kind of security check and not allow access to the target object?

I do agree that there are similarities in that they both contain a "HAS-A" and an "IS-A". However, the "IS-A" for the decorator must be the same as the target object while the Chain of Responsibility is not.

Then we turned our attention to the Decorator and the Proxy and there again are the similarities. Both must implement the same interface as the target object. But the Decorator has an instance of it's parent type while the Proxy has an instance of the target object. Does that just imply that Decorators can be nested while a Proxy can not?

Continuing to search for these answers...