OK, let’s say you’re on a Scrum team that’s planning its next iteration. You pull a story to implement Feature X for the next release of Application Y. You review the specs, maybe have a conversation or two with the product owner to clarify a few details, and discuss implementation details with your team lead. Cool. Now, you design the feature, code it up, build it and tweak it until its working to your satisfaction.

Then you check it into the source control system and move on to the next feature. Done, right? Not necessarily so! Sure, you can stand in front of the users at Sprint Review and watch them salivate as you demonstrate Feature X in action. But, can they walk out of the review and begin using it right away? Most likely not. If not, is it really done?

“Code complete” is just one milestone on the yellow brick road to Emerald City, where users are happily whistling away while using your excellent Feature X in their Application Y. There is so much more to consider. What about unit testing? Integration testing? Acceptance testing? Documentation? Packaging? Deployment?

Getting an application successfully delivered involves much more than working code. Failure to take this into account, and considering “code complete” to mean the same thing as “done”, inevitably causes a development team to fall behind schedule as they scramble to deliver what was already considered done. This is a form of technical debt, a topic I’ll explore in a future post.

For more information on the meaning of “done”, check out this excellent podcast on HanselMinutes.com:

What is Done? – A Conversation with Scrum Co-Creater Ken Schwaber

A bug is a bug is a bug, right? Not so!

Most development shops treat a bug as a task. That seems reasonable - it's a bit of work that needs to be done. Unfortunately, it's not so easy. If a bug is discovered in a feature that is currently under development, and it will be fixed in the current Sprint (iteration), then the bug can and should be treated as a task. It would be considered a new Sprint Backlog Item that must be closed before the feature can be considered "Done". However, if the bug is not fixed before the feature is considered "Done" (yes this really happens), or the bug is discovered after the feature has be deemed "Done", then the bug becomes a bit of work to be scheduled into a future Sprint. In other words, the bug should be treated as a Product Backlog Item.

The rule of thumb is rather easy really. If the bug is going to be fixed in the current iteration, then treat it as a task. If not, then the bug needs to go on the product backlog and be prioritized right along with all the other Product Backlog Items.

Of course, this raises the question: What does "Done" mean exactly? Many dev teams grapple with this deceptively simple question. I'll explore this question in a future post.

That's good advice. I find it helpful to do both. We create high-level objectives of the sort you listed like, "Reduce the number of bugs being released", "Assimilate new team members more easily". Then we create a list of milestones related to one or more high-level objectives. One or more team members takes ownership of achieving milestones which are more specific like, "Research and purchase a good book on unit testing techniques", "Create a Continuous Integration build for all code branches", "Create the Visual Studio 2005 section of the coding conventions document".

In a recent study, a group of Microsoft workers took, on average, 15 minutes to return to serious mental tasks, like writing reports or computer code, after responding to incoming e-mail or instant messages. They strayed off to reply to other messages or browse news, sports or entertainment Web sites.

“I was surprised by how easily people were distracted and how long it took them to get back to the task,” said Eric Horvitz, a Microsoft research scientist and co-author, with Shamsi Iqbal of the University of Illinois, of a paper on the study that will be presented next month.

“If it’s this bad at Microsoft,” Mr. Horvitz added, “it has to be bad at other companies, too.”

1. Customer - "Your stupid app lost all my contact data!"
2. Help Desk - "Maybe I can help.  Go to Help -> Analyze"
3. Customer - "OK.  I see this list of green and red dots with text."
4. Help Desk - "Can you read me the line next to the first red dot?"
5. Customer - "It says 'Can't find database at C:\myapp\contacts.mdb'"
6. Help Desk - "Hmm...  Can you browse to that directory?"
7. Customer - "No, I deleted it to have room for more mp3's"
8. Help Desk - "Oh...  That's a file required for our app to run.  Did you subscribe to our backup service?"
9. Customer - "Yes."
10. Help Desk "Good, go to Tools -> Options -> Restore Contact..."

You get the idea.  It rocks for troubleshooting those pesky support calls from customers.  For a lot more information, and a very nice screenshot, see Adam Cogan's original posting on this topic!  You can find the specific recommendation in his menu unit tests best practice. (While you're there, check out the rest of his best practices, he has a huge number of great ideas.)

Unfortunately, you cannot ship your Team System unit tests with your application.  I know there's an NUnit to VSTS Unit Test converter.  Does anyone know if VSTS Unit Tests can be converted to NUnit or MbUnit unit tests, so that all of us using VSTS Unit Tests can implement this best practice?

UPDATE:  Adam Cogan claims he got the idea from James Newkirk (of NUnit fame).  That may be the case, but I'll have to credit Adam.  :-) He's got so many best practices on his site (see this rule that covers shipping unit tests for an example) that if he didn't get the idea from Newkirk, he likely would have thought of it himself!

UPDATE TWO:  This IS Adam's idea!  James simply wanted a distributable test harness for developers to use!  I misunderstood his first comment to me!  (By the way, if you have comments on this post, or any other, please send email to steve+comments[at]accentient.com.  We've had to disable comments until we find a way to more effectively eliminate comment spam.)

Here's a great tool for agile development that was mentioned in a blog post below.  Go get a stack of these!  Shuffle them, pass them around, put your use stories on them, and slap them up on the board when you're ready!  Here's one more link.

Post-it® Sortable Cards only stick when you want them to! Now you have the flexibility to visualize and organize when and how you want on many different surfaces. Cards also easily sort, shuffle and stack together so you can use them again, or store them for later.

1. First, you need a build script for your continuous integration builds.  This script runs every time someone checks in code (with certain restrictions).  You likely won't want an aggregate report on these builds, except for rare cases -- there are just too many of them.  This build is optional.  I'm a fan of CI, but if it's a bridge too far, don't worry.  The critical build is the nightly build...
   
2. A TFS Build for your daily / nightly builds.  This build runs every night at a set time.  This build shows you what was accomplished during that entire day, including quality metrics, code churn, etc.  This is one of the most valuable builds, since its reporting is clearly segmented by time -- one build per day.  This allows a team to see what is being accomplished on a day to day basis.
3. A TFS Build for weekly builds.  This runs every weekend.  Like the daily build, it will allow the reporting engine to show you what was accomplished that week, and how quality changes from week to week.  This allows you to see aggregate changes over a chunkier time sequence, namely weeks. 
   
4. An end-of-iteration build.  I've found you don't need to go any longer than weeks this for most projects, as far as reporting is concerned.  However, you may choose to create a build that runs at the end of every iteration.  This gives you metrics on what was accomplished during the entire iteration.
5. An on-demand build.  This one is used for folks who just need to trigger a build whenever.  Unless it's necessary or useful, you may choose to have this build not report anything back to the data warehouse.