If a story has some defects logged against its implementation, does this mean it's not done? What does your [DoD] Definition of Done say about this? If a defect is severe or blocking other teams or other testing, then I would agree that the story really isn't done. In that case the team should probably postpone other feature work and focus on fixing the defects. However, if the major business value is still delivered and the main functionality is not adversely affected by a defect, then I would support the story being called Done (all other done criteria being met of course).

The product owner of course will want perfection... this is to be expected. There is a line however, somewhere, that separates a story from done to not done. However "no bugs" is probably not it... minor defects that do not block the major functionality, other teams, or other testing / features should be logged as defect stories on the product backlog, prioritized highest (even above other high-demand features) unless they are so minor that the story could ship to production even with the existing defect uncorrected.

Perfection is not in the Agile Manifesto the last time I checked... however the defect vs. done issue continues to remain a gray area.

The recommendation is this: classify defects based on a priority.

Pri-0 - blocking bug, drop everything and fix NOW.
Pri-1 - non-blocking but serious bug, broken functionality. Fix ASAP.
Pri-2 - non-blocking with work-around. Fix when possible.
Pri-3 - non-blocking minor issue, does not block functional testing. Fix if possible.

I support the in-sprint fixing of Pri-0 and Pri-1 defects, but any else should be deferred to another sprint. DoD should include this as a working agreement, and any reasonable [practical] product owner should approve.

So, what's in your Definition of Done?

Ever try to do Agile for a project or team inside a traditionally waterfall organization? It can be challenging... One aspect I noticed is trying to get from Requirements Documents to user stories. This translation is not an easy one typically. So, how is it done?

The Business usually has a set of things they'd like to see accomplished, and they have someone outline these in a Business Requirements Document. Then, it goes to an analyst so they can figure out the in's and out's of what the Business wants, and how best to specify them for development. Neither analysis is usually complete, and there are almost always holes and gaps that neither team has thought through.

After the BRD is produced and the Functional Spec document is written, some analysts may write Use Cases, an actor-action based description of a specific path that illustrates the functionality desired: "a bank customer uses his card at an ATM to withdraw cash." Use cases usually describe the "happy" path of a transaction, and perhaps some anticipated alternate paths, as part of the same case. The great thing about these use cases is they give a more or less concrete example of how something is envisioned to operate.

Use cases can be converted fairly well to User Stories - if this is something the team is using to scope their work each iteration. A use case typically represents multiple user stories, one for the "happy path" and several alternate paths to specify functionality when something does not go exactly as planned. Each of these paths can usually represent a complete and independent story.

When writing user stories based on requirements, using the use case as a tool to map out actors and actions does help bridge the gap between a requirement and a real story. Most often, the true "requirements" can be actually represented as acceptance criteria for a story. For example, if the user story is "a bank customer can use his card at an ATM to withdraw cash," an acceptance criteria might be that he must enter his 4-digit pin, and that pin must be verified by the central bank before any access to money is given, etc.

If we can get the analyst-role people to think in terms of use case analysis for a requirements doc or functional spec, we can much more easily get to user stories that meet the INVEST model (Independent, Valuable, Estimable, Small, Testable). True INVEST user stories can be tricky to write, unless someone is very experienced in this transition, and use cases are a commonly known mechanism that can help bridge this gap.

Today we used a new "Roundabout" mechanism in our daily stand-up, which is in a conference room. We have our artifacts on the walls, and our focal point for stand-up is our sprint status board with our story cards (large post-it's) and tasks on a progress chart. We use this chart in addition to an electronic mechanism to track the progress through the sprint. We have been just each standing around the table and pointing to the story cards and talking about our progress and status.

Today, (at the suggestion of a team member) we each stood by the chart, moved our tasks and story cards as appropriate, and then all the team moved around to the right walking around the table, so the next person could stand by the chart and talk about their tasks. I think this worked very well, as it kept focus on the team member speaking, and the team member was able to focus completely on the tasks and stories on the wall by physically touching them. It helped keep status focused and short. The movement around the room and around the table gave us a new perspective on the room and the chart, each time someone was speaking. Also, it gave us some physical motion to keep our bodies and minds engaged and present. Stand-up was shorter, and more effective. All the team felt that this was a good new addition to the daily routine, and the team is now wanting to add this movement to our working agreements.

Just moving around a table one team member at a time is a small thing, but it's FREE and seemed to help focus and productivity, so I am going to suggest the mechanism to any scrum team I have the pleasure to be part of in the future. Try it out and see what happens!

As you can guess, am not blogging anymore, am using Facebook and Twitter instead.

Catch me on Facebook at http://www.facebook.com/jboal and Twitter id JEBOAL