Acceptance criteria are the key to making sure our stories are done, and have as few bugs as possible. When the criteria are weak, not complete, unclear or misunderstood, this can be the root of a whole host of problems. Acceptance criteria are a critical point on which a team can focus to improve their results and delivery.

Acceptance criteria can be implemented as automated acceptance tests. The PO, the Developers, and the QA people on the team should all be in agreement that the acceptance tests do illustrate that the software works as desired.

I wrote another article with more thoughts on acceptance criteria, in a recent post on the TestDrivenDeveloper.com blog site, please check it out!

Acceptance criteria can be a tricky bit, especially if the customer and the team don't have much experience at generating and capturing them. I would definitely consider it a process smell if I saw a continuing pattern of low quality acceptance criteria. Really this can kill a project if left untended to fester on its own.

From what I have seen on several teams, we should all focus more time and effort on acceptance criteria gathering and then automating it in the sprint as part of the criteria for Done.

If you have mechanisms or practices that enhance or enable better collection or identification of acceptance criteria, please post a comment below.

"As a user, I can select my preferences and save them

so that the program will do the right thing."

ahem...

Sometimes we in the software business need to realize that the people using our software are not experts in the field. We must become experts at understanding the requirements and implications of the domain for which we write software, but we can not expect our users to do the same. We must be able to make some decisions with the software so that it does the "right thing" for the user. In today's world, software users have little time to fiddle with settings or options. They just need the software to do a job for them and do it the right way the first time. Our impatient "get it now" society of users definitely has this attitude. If our software doesn't do what they need it to do, they will more likely abandon it for something else before attempting to fiddle with settings, parameters, options, and preferences.

Our product owners need to be keenly aware of this attitude, and get the balance right with the features and stories that the customer base needs. While this is not an easy task, it is a very important one. As our software gets smarter and smarter, it should be more aware of what the user is attempting to accomplish, and it should make some decisions and assumptions based on the mode of intent. In addition (here is the key point missing from most software today) we need to *tell* the user what the mode is, and what the assumptions are. If we got it wrong, or the user wanted something else, then s/he has the opportunity to change the operating mode before the software attempts to do the "wrong" thing.

A "mode" could be an entire slate of preference settings, that come packaged out of the box with the defaults set for performing a specific task, or scenario. This entire slate could be modified if the user is advanced and cares to fiddle with them, but having the entire slate saved as a set, that could be chosen as a very simple selection. Then, always make it clear what the system operating mode is, and how to change it.

Keep it simple by being smart about what the user is trying to accomplish and make some decisions. Select the most appropriate mode, then - most importantly - communicate those decisions to the user, and let them know what the software is assuming about the task they are trying to perform. Give the user choices about how to control the software, and change its mode, but keep the goal to be helping the user stay more focused on performing the task at hand.

"Obviously, Development should be responsible for the acceptance tests. The developers are the ones on the team who are the best at writing good code. The developers are best able to turn the acceptance criteria into valid executable specifications. Development then can use the automated acceptance tests to drive the development TDD cycle."

"In QA, we never totally trust the developers. We do trust them to do the right thing. However, we have a saying in QA - Trust but Verify. QA should be responsible for the acceptance tests. At the end of the day, it is our job to make sure that the software meets the criteria for acceptance, so it's really a QA ballpark. Dev's should focus on unit tests."

Two strong opinions, and really I think both are right. Development should be using acceptance tests to drive an ATDD cycle. Developers are (usually) better at writing code than SDETs, so they do a more efficient job on acceptance tests. But QA probably has a more even overall view of the software, and from a different and more independent perspective, so they should be writing the acceptance tests as well as the other test automation. QA also has the responsibility of signing off on the code, so they should be writing the acceptance tests.

So, this may be one way to resolve the issue. Have developers and testers both work on automated acceptance tests for the first story. When the tests are completed, developers are free to begin working on the unit tests and code to satisfy the acceptance tests. QA can then begin test case generation and automation implementation.

I believe that this solution is the best of both worlds, because Development and QA will be completely in sync and on the same page for all of the stories where the acceptance tests are co-developed. There won't be any ambiguity on whether the software meets criteria, and both teams will be in agreement as to what is passing and what isn't. The tests will be well-written, and they will run as efficiently and accurately as possible. They will be written with multiple perspectives - the customer (who supplied the acceptance criteria), QA who makes sure that the test accurately guarantees the outcome, and Development, who makes automation quicker to implement and more efficient.

With automated acceptance tests co-written by dev and test, we have a great common point of communication, and a good example of how teamwork can really help software shine and inspire confidence and trust in the eye of the customer.

I have posted the acceptance test code in both Selenium and WatiN on the AgileBUG.com site. This code is a short demo and example of how we can do acceptance testing using both tools. The presentation is a short one on what ATDD is, and why we should do it. It serves as a prelude to the tools demo.

Join us at the Owl and Thistle tonight in person for a pint and some good agile discussions!

The UW Extension for Professional Development and Continuing Education now has a Certificate Program in Agile Development. It's being taught by some guys I used to work with first-hand, so I happen to know they are all pretty good at Agile Development. They are certainly highly qualified, and this certification course is a good opportunity for those folks who may not be as familiar with Agile principles to get some good instruction on how to do it well. Be sure to apply now, as this course is likely to fill fast.

The next Agile Beer Night is on Thursday August 21 2008 5PM to 8PM at the Owl and Thistle Irish Pub and Restaurant at 808 Post Avenue in downtown Seattle.

More information can be found here at the AgileBUG.com web site. There will be a presentation on Automated Acceptance Tests, and UI testing. It's a great opportunity for networking and just having a fun time.

Please tell everyone... track it back... spread the word... oh - and SHOW UP!!!

Carpool if possible. Bus if able. The location is on the corner of Post and Columbia, around the corner from the Mae Phim Thai restaurant, and just below the Fado Irish pub.

The food is good, they have lots of beers and it will be happy hour, so it's $3 burgers, $3 fish and chips, and $2.50 beers and well drinks!

Today's nerd dinner was successful... let's make this event successful also!

Practice agile? Want to? Like to meet some folks who do it well? Then let's get together in Seattle for a pint and discus Agile!

See you there...

I have heard a lot of discussion lately about the use of the "#region" directive in C#. There are various camps (some religious) on this topic, so let me throw in my twopence.

Many developers like to use regions to collapse sections of the code because it makes it easier for them to focus on a particular section. That's nice.

If there is that much code in a single file (which *should* be only ONE class), then there is probably too much code in that class. Class design should be focused on one specific thing. According to good OO principles, classes should be autonomous, and do one specific thing. Classes should be intelligent groupings for functionality relating to a specific, focused purpose. The use of the region to group code bits together in a file is a good indication that there is probably too much code.

Simplicity is a highly desired principle in software development. It's the simplest thing that gets the kudos, not the most complicated. Developers who try to write complex, convoluted code so that they can look good to their peers are really doing the opposite. Added complexity is very costly, in time for other people to understand it, debug it, and maintain it.

Here are some ways to determine some code smells in this area.

• Do methods have more than 25 lines of code? If so they are probably too big - this is a code smell.
• Do classes have more than 12 methods? If so, this may be another code smell. Classes that have lots of methods probably are doing too much. See if they can be broken out into more focused pieces.
• Are there more than 3 constructors? Sometimes a lot of constructors could be a code smell indicating using a class for different things in different places.

Anyone else have any metrics that they use? Please respond with comments below.

These kinds of things should be completely discussed on a team, and woven into working agreements, and coding standards guidelines. Teams that work within these are the most productive because everyone is on the same page and playing by the same set of rules. If your team doesn't have a guideline for these kinds of things, I would encourage you to write one up today and get input from your team.

How to Fix Problems on an Agile team - Examining the Evidence
In this article, I discuss how we can look at the artifacts produced by an agile team, to assess the fundamental health of the team and the business value the team can produce. Then, I offer a means to fix the underlying issues that we discover as symptoms of the problem. Here is one example of a practical approach at looking at some specific assets and artifacts, tracing back to a possible root cause, and an idea on how to fix it.

Artifact                       Cause                                  Fix

Engineering Debt                   Not refactoring design iteratively        Train developers in refactoring
Developers need to understand what it means to refactor a piece of code. It isn't enough to explain what refactoring means without giving some good examples. Many times I have seen what I call "superficial refactoring" where only a few things are touched, so as to minimize changing the code that's already there. I have heard developers say "well, I don't want to touch that code because [it is currently working | I don't have time to fix it | I don't understand how it works]" so, they leave it alone and just add their blob of new code, which now sticks out like a wart. It was not part of the initial design, and now that the initial design is obsolete (in some form), we now have engineering debt in that the design of the old code was not updated to reflect the now new "whole" image including the new functionality. Watch out for superficial refactoring, and if it happens - be sure to train on how to do a complete refactoring. Note: this might cause developers to estimate stories higher, since they will be thinking more of the actual work needed to be done...

Lots of Bugs                           Not enough tests                                 Unit test, use TDD, train developers in testing techniques (use QA to help)
Test Driven Development is a good mechanism for reducing bug count. But, sometimes it is a hard-sell to developers who have been "traditionally" trained. Also, sometimes it is a hard-sell to management who will only see that it is taking longer (at first) to get main line code written. Over a few weeks, lights will come on for developers, and they will begin to see the benefits of testing the code first, and letting the code evolve as a response to the tests. Bugs will be much fewer, because the developers will need to consider more things when they write tests. Having a QA person assist the developers in writing these tests can be very beneficial as well, as they will be able to give guidance in testing appropriate areas of the code such that bugs will not be written into the software in the first place.

Failure to Complete Stories      Stories Too Big / Too vague               Focus on DONE criteria, swarm on stories, better task breakdown in planning
I see not completing stories is a process smell. There are a variety of reasons this might be the case. Perhaps the team does not have enough clarity on what actually needs to be accomplished in the story. This is usually evident if the planning for a story goes very quickly and no/few tasks are broken out. Also if stories are too large ("epic" stories) we should break them out into separate smaller stories that are easier to estimate. Many times during a sprint, I have to add tasks to a story because I hadn't thought enough through the component pieces that needed to be modified until I actually got into the work of the story. Sometimes this is unavoidable, but mostly I consider that I should have spent a bit more time in planning for the story so that I had a better grasp of the work involved. If I get my team to help me work on tasks on a story rather than starting a new story ("swarming"), this can be an effective means to get stories done. This is not always practical, as some stories have tasks that are very interdependent, and it's difficult to get a lot of people to be able to work these effectively. However, if the team has enough discipline, focusing on stories that aren't completed before starting new ones is a great way to have stories finished at the end of the sprint.

Customer Dissatisfaction          Customer is not the Priority                PO focus on customer value, get customer in the room
The customer (or stakeholder) doesn't like what the team produced. It can be a variety of issues that causes this problem. Perhaps the PO didn't get the right idea from the customer. Perhaps the ideas did not get properly communicated to the team. Perhaps the team is more interested in some technology than giving the customer working software... Sometimes relevant stakeholders (Operations or Management, for example) were not involved or represented by the PO adequately. The team needs to make sure they understand what the customer's priorities are, and why. Satisfying the customer also must be the primary focus of the team. This information should be given to the team during planning, by the PO. The team then has the opportunity to ask all the questions they need, to be able to understand the customer's needs fully. The PO and the customer should be accessible by the team during the sprint, so that if there are questions that come up during the work, they can have answers in very short order.

Use these strategies as a starting point for assessing issues. These aren't the only things that can be analyzed, but in my experience I have seen all of these come to light on one team or another. These are only starting points, ideas to get an analysis moving. Please respond with comments if you have some different specific experiences that could help other readers as well.