The 7 Bullshit Agile Estimation Problems

Estimating stories for an upcoming project is one of the more difficult tasks that agile teams have to perform. It’s never easy to determine how difficult it will be to implement a particular feature, especially when you’ve got different personalities, goals, and levels or experience in the same room. Unfortunately this all leads to people coming up with excuses and roadblocks which lead to inaccurate estimates.

I’ve identified seven problems pitfalls of the agile estimation process that I’m sure many other teams have experienced:

1) Estimating Time Rather Than Complexity

The point of estimating stories with planning poker cards is that you estimate based on the story’s complexity, not on how long it will take you to complete the actual feature. A story that’s an 8 is more complex than one that’s a 5, but it doesn’t meant that the 8 will take two days. It could take an hour or a week, it’s all relative.

Why it’s Bullshit
Estimates based on time make planning commitments difficult and velocities unreliable.

2) Not Estimating For “Simplest Possible Solution”

The “Simplest Possible Solution” is just that, what’s the simplest way that the feature described in the story can be implemented. When you get away from this you start going down all sorts of “what if” roads that always end up bumping up your estimate.

Why it’s Bullshit
Trying to guess what the product owner will want or what the completed feature entails is a waste of time.

3) I’ve Never Done That Before

There aren’t many software problems that haven’t been solved. Most of them are things that have been solved a thousand times in a hundred different ways. Adding complexity to a story because you’ve personally never solved that problem is shortsighted.

Why it’s Bullshit
Just because you’ve never done something doesn’t mean it’s complex. Lean on your team or network of developer peers to help solve these problems.

4) Estimating Stories In Excessive or No Isolation

Stories should be estimated in isolation, just as they should be written so as not to depend heavily on one another. However, developers will often try to assign too much complexity to a story because of assumed tasks or features that they think would accompany the story in a completed state. For example:

As a user I should be able to login
As a user I should be able to upload a profile photo
As a user I should be able to change my address

Some developers will see the first story and immediately think of the complexity of creating a user model, the controllers and views that go along with the entire registration process.

Alternatively some developers will see the last story and think “Oh I just need a form field for the e-mail address when the user is editing their profile.”

Why it’s Bullshit
The first extreme gives you chunks of related stories with too much padding that are never as complex individually as they are as a whole. The latter only (sometimes) works when the actual stories are extracted out into a bunch of very small stories, which has its own set of problems.

5) Gaming Velocities

If you’re looking to “guesstimate” how long a project will take to complete, you could grab some story cards and pick out what you think might be a week of work. If you add up the points assigned to those stories you’d have an estimated velocity. However, if you’ve padded your stories, or purposefully pick out a small number of stories, your project is going to appear much lengthier than it really is.

Why it’s Bullshit
You don’t look any better completing 50 points per iteration when you padded the hell out of your estimates than you do when you do 20 points per iteration with accurate estimates.

6) Always Assume The Worst!

There seems to be this mantra with some developers, “Always assume the worst!” When you come across a slightly vague story, let your imagination run wild and assume that the product owner is going to want the most complex solution possible.

Why it’s Bullshit
Remember, every story is a negotiation. You’re not going to know the exact details of the story until you have your planning meeting with the product owner. Often times the product owner would never have been able to dream up the solution on which you based your estimate.

7) Padding Padding Padding

Padding is all Bullshit
The problem of padding estimates creeps into nearly all of the above six issues. It introduces bad data early in the life of the project and makes every other step of the process unreliable. It’s almost always in an effort to cover one’s ass but it’s painfully transparent and reeks of amateurism.

Don’t pad your estimates.

Make Fun of Your Client To Prevent Defects

One thing I’ve always heard about learning a new language is that you can’t consider yourself fully fluent until you can tell a joke. Telling a joke requires the understanding of homonyms and how words flow together. “So a guy walks into a bar…” sounds different than “A man enters beverage store…”.

When dealing with clients, it’s easy to joke about your client, but don’t miss an opportunity to prevent future missteps once you know more about them.

How often do you get off the phone with a client and immediately have a funny remark about some critique or issue they have mentioned. Typically this manifests itself when the client brings up an issue, that while important to them, is considered trivial by the developer.

Can you believe this guy!? I built out this whiz-bang feature and he’s just complaining about the font being too small!

The key part of this interaction is that you’ve now got a little insight into what makes this particular client tick. When you demo the next few features and he is unimpressed by the functionality, but comments on the spacing of form elements you should skip the joke and make a mental note for the future.

Once you can tell a joke about your client, before the interaction, and you have an “I told ya so!” moment with yourself or your pair afterwards, you know you’ve made it to the next level of understanding that client. Now, the next time you deploy a feature, discuss requirements or ask a question you can preempt the inevitable by accounting for those quirks and personal preferences of your client.

Instead of making a joke, make them happy, then you can both smile. ;)

The FAIL Monster Loves Excuses

Do you remember watching the FAIL Monster on Sesame Street? Never heard of the FAIL Monster? Weird, I’m pretty sure he was Cookie Monster’s cousin or something. He would pop-up and sing a little song about your failures and then at the end he would go crazy and NOM NOM NOM all of your excuses. The really strange thing is that when I grew up, I still saw the FAIL Monster, except he was all over, eating up everyone’s excuses, not just mine. When was the last time the FAIL Monster paid you a visit?

The FAIL Monster Is Your Worst Best Friend

When you first meet him you’re trying to figure out what this asshole is doing hanging out right after you really screwed up. You realize that he’s no good, but as time goes on, you start enjoying his company. He loves showing up because he knows there will be excuses aplenty.

Here are some situations when you might see him:

  • You’ve messed up and can’t take responsibility
  • The project is off track and it’s not at all your fault
  • If only < outside agent > would have completed < task > on time
  • You start using Fat Bastard’s circular logic to explain away your problems
  • “I don’t have < resource > to do < what is right >
  • You don’t write tests

Put the FAIL Monster on a Diet

Here is a quick guide to help you trim down your personal FAIL Monster:

  1. Quit making so many goddamned excuses!

Stop making excuses for your lack of understanding, your irresponsibility, your lack of prospects and your shit attitude. Take the time to push yourself, learn a new skill, read a book, meet people, take a leadership role, achieve greatness and succeed.

You can make excuses for everything, the only thing they’re good for is feeding your own FAILURE.

Why I Fell in Love With Agile

I’ve been working at Integrum for nearly 5 months now. When I started, agile was a concept that I had read about, but never experienced in practice. I took bits and pieces of advice from books like Extreme Programming Explained and Practices of an Agile Developer but I had never really lived day-in day-out as a developer in an agile workplace. However, now that I’ve experienced the project boards, burn down charts, velocities and story workshops, I cannot imagine going back to the slam-your-head-against-the-wall waterfall approach from which I came.

What I Love

Project Boards – Nearly real-time visual feedback on the status of your project. Everyone on the team can assess your project at a glance and you can avoid long status meetings with middle management. Greatly increases accountability.

Stand-up Meetings – Quick, informative useful meetings that don’t waste people’s time. Social group pressure keeps people who like the sound of their own voice from talking for 30 minutes.

Daily Client Interaction – No need for ego-maniac project managers. Developers discuss issues with clients each day so that they can deliver the best software with the most value as quickly as possible. Challenges or roadblocks can be brought up almost immediately helping to prevent wasted time on either side of the equation.

User Stories – “Replacements for a conversation” as I always hear around the office. Replaces the need to confusing spec documents and misguided feature requests. These provide a way to ensure that neither the client’s money or developer’s time are being wasted.

Acceptance Criteria – It’s not easy getting quality acceptance criteria from your clients, but man is it worth it. Helps to make sure that what’s “done is done” and there are no disputes towards the end of the project about what is or is not completed.

Short Iterations – Allows the developer to focus on a set of the most important tasks for a short period of time. The client receives frequent demonstrations of the completed work and changes in course can be made very quickly. What was important 4 months ago during the original planning session might not be important this week.

Waterfall Development: DO NOT WANT!

Looking back on my last job where waterfall development was the norm, I can’t imagine how I got anything done. When I really think about it, I wonder how much software I wrote that was “right” the first time around.

Just as a quick list, here are some of the things I’ve grown to hate:

  • Project manager dominated client interaction
  • Long useless meetings
  • Finger pointing and blaming and lack of accountability
  • Waiting a few weeks to find out that your implementation is incorrect
  • No way to tell what was actually “done”
  • Wasteful spec documents

This Won’t Work For My Business

There are probably a lot of development shops that are humming along using long standing processes based on a waterfall model. A lot of people probably think that they don’t need to change because “if it ain’t broke, don’t fix it”. If you’re not doing agile your shit is broke!

A lot of managers probably think that this system won’t work with their employees. I can see this being the case if any of the following apply:

  • You don’t trust your employees
  • Your employees are morons (or you think they are)
  • You think you need to operate like the status quo
  • You can’t give up your control on the process
  • Your clients suck

Agile Works at Integrum

Derek Neighbors has taken the time to produce a couple of videos outlining how agile is put into action at Integrum:

Whatever the reason, agile works, like actually works, at Integrum. Is it the culture? The people? The atmosphere? The expectations? The clients? I can’t quite put my finger on it, but I can guarantee it’s not coincidental.

Quit Being Comfortable!

Life treating you nicely? Everything going well at work? Having fun on the weekends? Feeling, comfy? Watch out! Sooner or later that warm blanket sense of security you get from your daily grind will start grinding on your happiness. If you’re not careful you’ll slip into a dip of comfort and satisfaction, risking little, gaining little.

If you’re heading towards that dip, or feel like you’ve been stuck there for a while, fear not, it’s easy to shake yourself out of it. Put yourself on the line and increase your expectations.

It’s easy to fall into comfortable relationships, comfortable careers, comfortable routines and lead a comfortable lifestyle. However, once you’re in that position you start to wonder where the magic went. You can recall a time when you were excited and things sparked your interest, now, they’re just boring old routines.

Imagine those exciting times. That time you spent dating, forging that good friendship, interviewing for jobs, meeting the new team, notice a pattern? They were all challenging times when you had to push yourself and risk something.

Risk being ignored, risked be disliked, risked being rejected, risked failing. You had to work hard and make things happen. Look where you are now, no risk, no challenge, no real effort.

Do yourself a favor:

  • Join a local industry group
  • Give a public presentation
  • Attend a local lunch gathering
  • Update your resume
  • Start a new project
  • Learn a new skill
  • Make a new friend

Put yourself on the line, risk something, challenge yourself, flirt with the possibility of failure. The feeling you’ll get from all of this will tear that comfy blanket to shreds.

If You Want IE6 to Die, Kill it

Internet Explorer causes web developers a lot of problems. Specifically supporting older, less CSS/standards friendly versions like 6.0. Internet Explorer 6 still requires a lot of hacks and fixes to get working properly and in some cases can limit your design. Complaints about Internet Explorer 6 (IE6) in the web development community are a dime a dozen, everyone wants to complain about IE6 but nobody seems willing to do anything about it. If IE6 needs to go away, let’s do our part to help, stop supporting it.

Is IE6 Support Really Needed?

A lot of people will showcase their attention to detail and thorough craftsmanship by detailing the different types of configurations they use to test their markup. Every version of Internet Explorer, Windows XP, Vista, Firefox 2 and 3, Safari on OS X, Safari on Windows, the list goes on.

I’m not sure if this time is always well spent. Sure, it’s nice to be able to say that you got your code working in all of the “major” browsers but what’s the trade off? Hours of time spent tweaking and tweaking your CSS looking for the fix to that magical bug causing some slight visual discrepancies in IE6 on Windows XP? Doesn’t sound like a good use of my time.

Analyze Your Access Logs

Here are some statistics I have compiled from three sites that I either built or maintain. One site is a lower traffic informational site, another is a medium traffic wealth building program membership and e-commerce website and the last is a high traffic travel website that receives a lot of traffic from paid search on Google and Yahoo.

I have combined the log files since June 1st, 2008 and used some basic unix commands to count the number of times certain user-agent strings were found.

Here are the results as a percentage of each user-agent:

  • MSIE 7.0 – 50%
  • MSIE 6.0 – 30%
  • Firefox (2,3) – 12%
  • Safari – 4%
  • Others – 4%

Not surprisingly, Internet explorer has a huge lead over the Firefox, Safari the “others” combined. What is worth noticing is that IE6 users only make up 30% of the total traffic.

Does the Page Render Well Enough?

Are you are spending time trying to line up two divs that are a couple of pixels off, reducing the font-size of a certain element by a few points or trying to get that margin to be exactly ten pixels instead of twelve pixels?

Stop, now, you are probably wasting your time.

A LOT of people who use Internet Explorer use that browser because it came with their computer and they don’t know or care about alternatives. They are not concerned with web standards and CSS compliance. If a website looks and feels like most other websites they are not going to notice some extra padding or misalignments of three pixels here and there.

These visitors, like most, want to find the information they were looking for or accomplish the task they set out to complete. They are not interested in the minor design bugs that might be present on your site.

Chances are your website would be better, for everyone, if you spent that “IE6 bug fixing” time improving the general usability and information architecture of your site. Wouldn’t that be a better use of your time?

But My Client Insists

A site you have designed for a client has a couple of visual flaws in IE6. Your client mentions them to you and insists that they be corrected. They are using IE6 to preview the site as you work and everything on must be perfect before they are willing to launch.

Ask them which item they are willing to forgo on their priority list to account for the time you will spend fixing that IE6 bug. Instead of giving in suggest that you complete all of the other major functionality, launch the website and then if it is still a problem you can fix it later.

If they have server logs from a current website or a sister website, analyze those and see what type of user-agent break down you’re dealing with.

Remind them that there are certain aspects of the website that will help them accomplish their greater goals and that these are more important than minor visual flaws.

Fixing IE6 Bugs Does Not Make you Special

Congratulations, you solved some problem related to IE6 rendering that someone else already solved. You do not get a prize, you do not get respect you do not get to boast. Please, find another way to boost your twitter update count other than beating the oh so dead IE6 horse.

Everyone is as sick of hearing about it as you are of solving it. It is like the ever-present bad beat story of web development.

Stop Supporting in order to Stop Complaining

You are in control of your own IE6 bugs, after all you wrote the HTML/CSS that is causing them. If people were serious about never wanting to deal with these problems they would take it upon themselves to never write code that causes them.

Here are some things to keep in mind when stressing about IE6:

  1. Test early and often – Check your code at major design milestones to see if you have gone off track.
  2. Learn from past mistakes – Which HTML/CSS combinations got you in trouble the last time?
  3. It doesn’t need to be 100% – Determine an acceptable level of IE6 compliance and stick with it.
  4. Analyze your visitors – Don’t waste your time fixing problems for a small audience

IE6 is not going away for a while, even as IE7 ships with each new copy of Windows. There will still be a lot of people using IE6 and that’s okay, the web doesn’t need to work 100% of the time for everyone in every scenario. I am okay with a user in IE6 seeing a slightly different amount of padding around a box or a little extra border at the bottom of my header.

Perfect the Important Things First

You should strive to make fixing IE6 bugs the last improvement possible. Doing so ensures that your usability, architecture, design and content are the best they possibly can be. If you can achieve that level of excellence your clients will love you, their sites with thrive and you will have something to to tweet about.

Designer v Developer Death Match

There’s been some interesting buzz going around about the role of designers and developers in the modern web development process. The demi-gods at 37Signals sparked some controversy when they posted about why they skip photoshop. Andy Rutledge posted an entry on his Design View blog about how to be an employable designer. James Bennett summed everything up nicely with his Designers and Developers: FIGHT! entry.

I’m surprised (and not at the same time) from the reaction from both designers and developers. Both want to keep their “I know something you don’t know” status while insisting that their jobs and skills are important. However, once we inject some professionalism into the debate it becomes clear why combining talents is the best scenario.

The Geek Ethos and Jock Revenge

Part of the greater geek ethos is that you’re a superior being who has used your talents to amass an amazing amount of knowledge and skill in a particular field. You step on those ignorant fools who can’t normalize a database or implement a design pattern. You have sacrificed your time and energy (and encounters with the opposite sex) to get to this level and Linus willing you will not have some pesky designer approaching your level of geekliness.

There is something about your average programmer, developer, dba and general nerd that gives them an inferiority complex where knowledge of a subject and skills in a work environment are treated like a zero sum game, “you cannot has mai skeels!”.

Study the Basics, Master Their Use

In the modern web development work flow, the best results occur when designers and developers work side by side to produce the end result. If the separation between the two is too great, there will be an obvious disconnect between the design of the finished product and the development of the finished product. Like a puzzle missing some pieces.

To achieve this melding of talents both designer and developer need to go beyond their comfort zones and learn something new from one another.

Designers

  • Learn basic HTML
  • Learn basic CSS styling and layout concepts
  • Learn how your developer’s program interacts with your design (the V in MVC)
  • Learn the basic concepts of your developer’s programming language

Developers

  • Learn the basics of information architecture, usability and visual hierarchy
  • Learn the basics of spacing, margins and padding for elements on the page
  • Learn how to use white space
  • Learn the basics of design (line, type, shape, contrast, texture etc.)

Ignoring Ego for Fun and Profit

If designers and developers can get past their own desire to be the most important person in the process and realize that their own personal short comings are what matter, the world of web development will be a better place. You will be amazed at how successful you are when you’re on the same page as your designer. It’s not enough to complain that the other person doesn’t know what you do and that they don’t respect your skills, drink your own medicine and learn what you don’t know if you want to become a better piece of the puzzle.

Fostering Successful Twitter Relationships

At a basic level, most prosperous relationships are a two-way exchange of value. If one party is neglecting the other and the balance of value gets out of whack the relationship becomes damaged and potentially fails. With this in mind I’ve been evaluating how I use twitter to interact with those who follow me and also those who I am following.

Twitter: A two way street

Twitter: A two way street

Permission and Tweet Spam

When someone chooses to follow you they are essentially saying “I find you interesting and want to hear more”. They are giving you their permission to interact with an expectation that you will continue to deliver the same type of value you were providing when they made that original decision. To make the most of this you should be mindful of what you’re providing and compare that to the noise you’re sending across the wire.

Someone to Ignore

There’s a passage in one of Seth Godin’s books where he mentions a study in which CDNow (the amazon-purchased-dot-com) ruined their customer relationships by sending them too many e-mails. At a certain frequency their once loyal customers determined that CDNow was something they could ignore.

Don’t pollute your relationships and become someone to ignore.

Low Barriers Of Friendship on Twitter

You don’t use twitter? You silly luddite! Okay actually I just started using it yesterday, I’ve had an account for a while but I never really understood what I was supposed to do with it. The idea that other people care what I’m doing at the moment seemed like a joke, however I’ve realized that there’s more to it than that.

That was Easy

That was Easy

.

Reciprocal Friendships

You have two basic relationships on twitter, following and follower. If I find you and like you for whatever reason I can choose to follow you, I am not your follower. On the other hand, people might find you and decide that you’re interesting and want to follow you. So after a few clicks you’re suddenly “friends”.

I find it hard to not to follow someone who has decided to follow me. It feels wrong not reciprocating the love and saying “oh you? Uh sure, I’ll be interested in what you’re saying too, sounds great!”. I have 1 person that I’m following on twitter that I’ve actually met in person (we’ve known each other for a while) the rest of them are unknown entities recognizable only by their 48×48 pixel avatar.

Twitter as a Networking Tool

Since I’m not really interesting in trying to form a bunch of online relationships with various people, I’m trying to approach twitter as a method to get in touch with people in my area who are interested in the same things I’m interested in. So far I’ve found a number of local industry experts, bigwigs and people I’d like to meet and have issued that first bit of contact. I’m now on their radar, fantastic. I’ve also found out about an awesome local gathering that I’m excited to attend.

It may be simple to follow and be followed on twitter, but if I remember “quality over quantity” it’s possible that I will create some very useful online and offline relationships that can benefit both parties. So what are you waiting for? Follow me on twitter

The Battle Between the Right Way and The Working Way

I’ve this got awesome full stack framework at my disposal, various books, videos, articles and open source examples, yet rolling my own commenting system was a challenge in and of itself (otsn: is this the same as ‘unto itself’). I thought I had things working for me with my nested routes and simplistic system, however I guess it goes to show you that even the simplest systems can be massively complicated and confusing in the right hands.

Posting to Nested Routes and Displaying Errors

I’ve got some nested routes:

1
  map.resources :posts, :collection => {:feed => :get}, :has_many => :comments

Posts have many comments as you’d expect. So this gives me nice URLs like /posts/5/comments/new and named routes like new_post_comment_path. Easy enough. The problem I ran into was following this common rails convention:

  1. Form is displayed when GETting a Controller’s new action
  2. User enters information in form
  3. Validation fails
  4. “new” action is re-rendered from the Controller’s create action

This is simple and not even worth mentioning for most scenarios, however I got myself in a bind when I tried to apply it to my posts/comments scenario.

  1. Post’s “show” action is rendered (PostsController)
  2. Comment’s form is displayed (PostsController)
  3. User enters information into Comment’s form and it’s posted to /posts/:post_id/comments (CommentsController)
  4. Validation fails and “form” has to be re-rendered (CommentsController)
  5. WTF now?

I can’t just re-render the PostsController’s show action (I messed around with rendering the template with render :template but that didn’t really work). I can’t render the PostsController’s show action again and hop down to the Comment’s form (I tried using :anchor and all sorts of shit, no luck). At this point I was really stuck, couldn’t really figure out what to do next, rails confidence shattered, ego bruised, internet more browsed… eventually I gave up for a few days.

The Right Way and the Working Way

There’s something about Rails that makes me want to do things the “right” way. I don’t even know what that means half the time, but something about the community, the examples, the general vibe of everything suggests that there is usually a “right” way. Sometimes I think I get a little too caught up in this. Coming from PHP where there isn’t really a “right” way, I think part of me is searching for some structure and validation where I can have some confirmation that not just BSing my way through a problem is a good solution.

I got to a point with this problem where I basically gave up. I shelved the problem for about three days, just kinda ignored the whole thing. When I finally came back to it, I had this genius idea to not be fancy and just display the Comment’s form on it’s own if validation fails. This works in that it solves my problem, it’s not totally out of this world usability wise and it has allowed me to move on to solving other problems and making new improvements.

When you’re at a crossroads of doing something the “right way” and the “working way” you need to ask yourself if it’s worth forgoing the “right way” in favor of the “working way”, often times you’ll find that the “working way” is “right” enough and you’ll save yourself a lot of time and frustration, saving your energy to tackle more important problems.

otsn: off topic side note, LDO