Geeks With Blogs
Robert's Blog ideas about design and development

About a year ago, I think I personally wrote off estimation as a dead waterfall practice and a pipe dream (not to mention a waste of time). To me, estimation stunk of something to keep the lawyers at bay. You lost me right there, but now I am back. Estimation is important to keep the customer happy, not the lawyers. My boss kept telling us to estimate stuff, but we kept on shirking his task. We had adequate enought time pressure to allow us to not think about how long the tasks at hand were going to complete. I think the problem there is that seasoned manager (and enginner) doesn't translate into young artist, but that is a story best told over a frosty beverage.

Giving a requested feature some thought and decomposing into estimatable chunks is an essential part of Scrum. I accepted this at face value when I read "Scrum and XP from the Trenches". Sadly though, I never really went on to understand why (or to really start doing decomp. and estimation). Recently we gave our customer team exactly what they had asked for, but at a price they weren't willing to pay. Wait a minute! Isn't that what Agile is suppose to prevent? We were close to being Agile but not quite there yet (not sure if we are yet either, but we are a heck of a lot closer). The development team and the customer team both learned something that day. The customer team learned that in order to get what they really want, they have to be more vocal. Written documents and emails alone aren't going to cut it. The customer team actually needs to sit down with the development team and use the app! The development team learned, you actually have to hold end of Sprint demos! The development team also learned that you have to decompose features down into what is really needed to deliver business value. That decomposition should turn into estimates that the customer team can use to adjust the scope of work (re-size the feature or break it up into pieces).

This really cemented in my head when I started reading User Stories Applied by Mike Cohn. Story Cards and their accoutremonts (estimates, priority and acceptance tests) are tools for the customer team to decide what to build when. You as developer are the facilitator of this process. Users don't know what they want. We all know this. That doesn't mean they don't know what they don't want (this is a fun dinner time ritual for the wife and I, I suggest eating establishments, she shoots them all down). The customer team should include a representative user or ten or at least a proxy for a representative end user. You facilitate the design process by starting the conversation. You all already know big picture what this thing is supposed to do at your first meeting. You need to decompose your epic story into smaller estimatable stories. If you have a large story that deals with creation (entering a description of a house perhaps) Mike Cohn suggests that breaking such a story down into logical groupings of fields that will fit on a single screen is acceptable (think tabbed form here people). You can get the ball rolling by doing Agile Modeling (I admit I am a beginner at this at best, and haven't read the book yet-although the book is in my satchel) by drawing a really watered down version of your main value object on a white board (a house perhaps) in a psuedo UMLish diagram. Once you start figuring out the properties of this main value object, just stand there at the whiteboard with dry-erase marker in hand and watch the magic happen (don't forget to keep diagraming though). This is called Brain Storming. You are trying to work out your ubiquitious language and the domain for your app. You just helped the customer team overcome a hurdle. You just started listening to their needs in their language. The hurdle was really a stereotype, and that stereotype is that all programmers hail from Vulcan and don't speak English.

Once you get past brain storming and are into release planning, you can keep Agile Modeling and turning the results of those discussions into User Stories. Once the User Stories have been sufficiently decomposed to estimate. You have all the developers come up with an estimate for that story. Then they all give their number. While they are haggling about the number, the customer team will realize the scope they had in mind is not what these developers are talking about at all. Developers usually want to make it ten feet tall and bullet proof. At this point, if you are a customer teamster, please don't haggle quality assurance with development, just reduce the scope of the story until it is what you actually need (better to get developers to give up on the ten feet tall thing than the bulletproof thing, for you, them, and the sake of your business). Or better yet, break the story up into parts if it is a complex or compound story and assign each new story a priority accordingly.

If the customer team has a good bead on what the end users want, this decomposition and estimation will help you deliver the highest value as soon as possible. Isn't that what we all want anyway?

Posted on Saturday, June 21, 2008 11:11 AM Agile | Back to top

Comments on this post: Estimate Yes, but for a Different Reason

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Robery Stackhouse | Powered by: