But It's A Defect!

Yes, the story is a defect story, but that most definitely does not mean that it automatically has the highest priority of any story in the backlog.

Even defect stories have business value associated with them.  It may not even be worth the cost in man hours for the development and QA of the fix for the defect in terms of how long it will take before the business sees a return on investment for that fix.

Yes,  defect stories are defects because they mean that a previously played story is not behaving exactly as it was supposed to.  But, there is also a portion of the original story that is behaving exactly as it was supposed to.  That means that it is entirely possible (and somewhat probable) that the defect will affect such a small percentage of the interactions with the system that the code fix for the defect will be much more expensive for the business than any manual (or otherwise) work-around that the business can implement to deal with the defect.

I am not saying that all defect stories are low priority.  There are the occasional defect stories that are exceptionally high priority.  For example, if a defect brings down an entire warehouse.  That has a very real cost associated with it the longer that warehouse is still down, so the faster that defect gets fixed, the better.

But, those severe defects are few and far between.  If they're not, that's a warning that something isn't right with the way you are doing things.  Perhaps you're missing a level of testing (unit, system, integration, end-to-end, etc.) or an area of your system isn't as well tested as it should be.  Or, perhaps it is an indication that a portion of the system needs to be rewritten to be able to better handle certain types of situations that were thought to be rare edge cases but turned out to be much more common.

So, yes.  I am saying that just because you found a defect, it doesn't mean that you have to fix it.  Some defects just aren't worth fixing because you'll either never get a ROI on it, or some other work-around for the defect will provide a faster ROI for the business.

You'll know the critical defects that need to be addressed immediately when you see them -- and so will your Product Owner.  Just like any other story, let your Product Owner prioritize your defect stories.  If they are leaning toward "all defects are critical", help nudge them back toward looking at what the real business value is in fixing the defects.

"Defect" is just a label that we're applying to help categorize stories.  Don't let the choice of word used to describe the category influence your impression of the importance of the story.  The categorization of a story is distinct from its prioritization.

Tech Stories are Business Stories Too!

"Say What?"

One thing that I seem to be hearing a lot of lately is that "Tech Stories" aren't "Business Stories" and thus shouldn't be subject to prioritization by the Product Owner.  I beg to differ.

Tech stories are just as much business stories as any other story that we play.  That they provide some value to the system being developed means that they are also providing business value; the system is being developed to serve the business.  If the system doesn't have business value, we have no business developing it.  Similarly, if a story doesn't have business value, we don't have any business working on it.  So, because the technical stories are providing business value, they should be subject to the same prioritization as any other business story.

"But, my Product Owner just doesn't understand why my Tech Stories are important!"

It's your job to help your product owner understand the importance of the story in terms that they can understand.

Yes, you heard that right.  You are the one with the technical expertise and knowledge, so you should be able to explain to your Product Owner why your technical story is important.  If you cannot explain to your Product Owner why it is important in terms that they can understand (i.e. in terms that relate to business value), then perhaps your technical story really isn't that important after all.

If a technical story is designed to provide better error handling around one section of the system, then it's up to you to explain how better error handling around that section of the system will provide business value to your Product Owner.  For example, the better error handling may mean less frustration on the part of your users.  Or, it may mean that Level 2 Support may be able to more easily diagnose and address the issue, which would result in fewer problems being escalated to Level 3 Support (which is likely much more costly than Level 2 Support).

"If I just tell my Product Owner that the world will end if we don't get to play this technical story, I can get him to let me work on it right away.  Why bother with trying to figure out the real business value behind it?"

Because, if you aren't providing him with an accurate impression of what the true business value is of your technical story, then you aren't doing your job to provide the best business value that you can, as quickly as you can.  Your technical story may be providing much less business value than several of the other stories that have already been given a high priority.  It is your job to give your opinions and advice to your Product Owner to help him understand what the business value of some stories are (or to occasionally nudge them away from "want's" and back toward "need's").  But, it isn't your job to determine what is going to be the highest business value for the business -- that is your Product Owner's job.

No matter what the technical story, there is business value within the story.  It's up to you as the developer to help your Product Owner understand the business value in it so that it can be prioritized correctly.

Agile: Getting Business to "Buy in"

When developers talk to business about Agile Development, they usually tell business about all the "wrong" stuff: pair programming, card walls, continuous integration servers, pulling time from the business to talk with the developers every day, etc.  Do not get me wrong, it is cool stuff -- for developers; unfortunately all it usually sounds like to business is, "this is going to cost me even more money, why should I do this?"

So, what is the "right" thing to tell business first to get them listening?  Tell them about how Agile is going to increase their ROI on projects and how it is going to give them access to that ROI faster.  This is not very sexy to most developers, but it should be!

As much as we developers might hate to admit it, we are not primarily getting paid to play with shiny toys and experiment with new technologies.  We are, first and foremost, getting paid to help the company we are working for make more money.  That usually means developing (or maintaining) software to help keep the company running smoothly, help them streamline operations, and be generally more efficient.  Doing this will save them money, allow them to expand into new markets, and allow them to better compete in their existing markets.  The faster we can do this and for the lower the cost, the better.  (Note that "lower cost" does not mean just the lowest immediate cost, but the lowest cost taking into account how those decisions will affect the business over time.)

There are two areas, that business can relate to well, in which Agile Development does an excellent job of getting the business their ROI faster: the frequency of deliverables and the management of project scope.

Frequency of Deliverables

Waterfall Development typically has an initial period of no coding, during which requirements gathering is performed, the scope of the project is decided, the system is designed, architecture decisions are made, and documentation is created to flush out all aspects of the system.  This period can take weeks to months, depending on the anticipated scope of the project.  During this time, no coding is actually done.

After this initial design and requirements gathering stage has been completed, a small team of developers will be tasked with creating one or more prototypes over the course of 6 months to 1 year and those prototypes usually have limited-to-no production-value use.  Assuming the prototypes have received approval, the full development team is then placed on the project and development begins in earnest.

There will usually be target dates 3-6 months apart, at which various milestones are set to be reached.  These milestones may or may not be accompanied by a limited-functionality production-ready version of the system.  The final version of the production-ready system is delivered at the close of the project (often 1 or more years out from the start of the project), after which the project is shifted into a "maintenance and support" mode.

Agile Development typically begins with a "sprint 0", during which initial requirements gathering is performed, the scope of the project is decided, an initial prioritization of the features is decided upon, and some story cards are written for the first set of features to be worked.  This sprint typically lasts a week at the most.  The requirements gathering needs to be complete enough to ensure that the product owners have a clear idea of what they want out of the project, the business analysts can give them a reasonable idea of what is going to be needed to accomplish those goals, and a budget and timeline can be set.  However, the requirements gathering does not need to be fully fleshed out as in Waterfall Development, as Agile assumes (and welcomes) some degree of emergent evolution of the project.

At this point, development with the full team is ready to begin on the highest priority features.  Depending on the scope of the project, new production-ready versions that include all of the functionality completed-to-date might be delivered every week, every two weeks, or every month.  Typically, waiting longer than a month to deliver a new production version is considered to be "too long" -- a month is even considered "too long" by many Agile developers.

This means that a month or two into the project, the business already has a production-ready version of the system that they can (and are expected) to use.  The business can then start seeing a ROI as quickly as a couple months into a project!

These frequent deliverables serve another, extremely important purpose.  Feedback from the users (the more users the better) will help the design evolve while the project is underway, which means that the project will ultimately more closely resemble what business actually needs than Waterfall typically does.  This feedback results in new features being added to the project, adjustments to the way future designs were going to be handled, and allows for defects that slipped through testing to be detected (and fixed!) early and often.


[Edited 9/5/2011 - Removed section on "Management of Scope" for revision and expansion.  It will be re-posted later as a separate entry.]