Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Friday, October 28, 2005

Are Functional Specs Redundant?

Should an agile project team write functional specifications? What about design documents?

The drumroll please....

And the answer is a resounding "It depends!"

For most agile methods, a feature begins as a "story" as told by a customer, and captured in some format, possibly an index card, spreadsheet, or more sophisticated planning tool. This story is considered a placeholder for the detailed discussions that will take place between the developers and the customer when implementing that story.

But in a situation without an onsite customer and frequent contact, there is certainly some value in capturing a bit more details about this story. This can take the form of acceptance tests, which are basically the set of things that must be true in order for your story to be considered "done."

However, in many organizations, there is a separate QA or test team that is expected to write test cases, run regression tests, and be able to trace their tests back to a set of documented requirements. The QA team often needs formal documentation in order to keep this all up to date. Now, some people would argue that they shouldn't be doing this, but for various reasons (regulatory or contractual, primarily) this is sometimes a real world requirement.

So for this situation, a set of detailed specifications is needed before any test cases are written, and the tests must map back to requirements. This typically means that business rules, user interface nuances, and other details must be discussed in the requirements, the specifications, and the test cases.

But doesn't this violate the Don't Repeat Yourself (DRY) principle? Why can't we skip the specifications, and just write acceptance tests? And given a full set of acceptance tests, slowly work towards automating as many as possible?

Well, one way of looking at this is that you've got increasing levels of detail and rigor as you work from Requirements to Specifications to Tests.

  • Requirement: The system shall accept orders from the web
  • Specification: Web Data entry form will take the user name, credit card, address, etc.
  • Acceptance Test: Login and go to the order entry page. Enter a credit card number. The system should validate it, and save the order to the database.

So when trying to communciate with other team members, you'd pick the level of detail appropriate to the task. Acceptance tests, especially the automated kind, are great for developers to exercise the system, but the format that's useful to developers may be difficult for stakeholders to understand.

The key is to know your audience. If you've got remote customers, you may need to communicate with documents, so here a functional specification has a lot of value. Similarly, if you're using an offshore development team, it's going to be even more important to write down the specifications in detail if you hope to get close to what you want.

On the other hand, a small team with onsite customers, and a commitment to automated acceptance tests might not need as much documentation.

Rule of thumb: Before writing any document, ask yourself "Who is this for, and how does it help them?" If you can't answer, or the answer is "No one, and it doesn't", then don't write it. If you have a clear need, go ahead and create the document, but be sure to have a strategy for keeping it up to date, or discarding it when it's past it's useful lifetime.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, October 19, 2005

Prioritizing Requests from Multiple Customers

I've written before about how to decide what to do first on a software project, which to summarize is something like:

Have the customer force rank what's most important, considering your input on how much each feature will cost.

But what if you have multiple customers, and you're expected to represent their needs? How do you prioritize possible features such that your product or system delivers a little something for everyone?

The "force-rank" approach works pretty well for a single customer voice, but for independent software vendors, or service owners with diverse customers, a little more is needed.

One approach that works pretty well in my experience is to use a "voting" approach. This basically lets stakeholders choose their favorites, while limiting them to a fixed number of choices.

For example, we've got a list of about 20 possible features for the next release of ExtremePlanner, all of which are useful and interesting, but we can't do them all, and probably wouldn't want to since keeping things simple is our core philosophy. So we need a way to meaningfully prioritize these features, considering the relative value to the customer base as a whole, and the impact on the overall direction of the product.

We like to consolidate the input from stakeholders (could be an actual customer, product manager, colleague, best friend, or family cat). Each voter gets to pick their top 5 most important features from the larger list. Features can then be ranked by the number of votes they receive, at least as a first cut.

After adding up the totals and ranking the features, a pattern will usually emerge. One or more features will be clearly more requested than others. Now combining this with the development estimates, we can start to put together a rough picture of what the next release might contain.

Now, this doesn't mean that we would only implement what the voting turned up, but its a powerful way to get a handle on what has the most meaning for our customers. Sometimes a smaller feature that didn't get any votes will make sense to combine with a popular feature to have a bigger impact. Or we may have to defer a feature that is too costly to implement, or that would make the product more complex to understand.

When deciding on priorities, your customer's voice is a key input. Even when there are multiple voices. The trick is finding a way to meaningfully combine those voices into a hit song.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Sunday, October 09, 2005

Designing Testable User Interfaces

One of the biggest challenges in software development is creating graphical user interfaces that are easy to test. For small teams especially, having the ability to automate tests that interact with the GUI can save a great deal of manual testing effort.

Conventional wisdom suggests that to test a GUI application, you should test below the interface itself, and design an application that has a very thin UI shell. But how would you test even a simple Scribble application that let you draw on the screen?

One approach would be to design the application to support scripting. In effect you create a protocol for the presentation layer than can be driven by automation. This is the approach that testing tools for Web applications take, since HTTP and HTML offer a well-defined protocol for both taking actions and rendering the results.

So for our Scribble application, we need to be able to draw on the screen, and test to see if what we drew actually appears. The protocol could be as simple as a way to plot a point, and a way to test if a point on the screen is plotted. And maybe a way to save and load the image.

- Plot point x, y
- Test point x, y
- Save as file
- Load file

With these simple primitives, we can now write automated acceptance tests for our Scribble application. We can test existing images to verify that what we know is in the file will be displayed properly in Scribble. We can draw to the edges and see if anything breaks. Most importantly, we can develop a suite of tests that can be run automatically whenever Scribble is updated in the future.

By thinking about how to design our user interfaces to be testable, we also allow them to be useful outside of their original intended purpose. Even our simple Scribble application could be controlled from a statistical package that doesn't have it's own drawing features to do some simple charting.

So make your user interfaces scriptable, and reap the benefits for testing now, and maybe something even more interesting later.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Monday, October 03, 2005

Are Acceptance Tests an Agile Specification?

Acceptance tests are less visible in Agile discussions than their more popular agile brethren, such as iterations, stories, and unit tests. But what exactly is an "acceptance test" anyway?

Well, to paraphrase the Rules page, an acceptance test is something the customer creates which will determine when a story has been correctly implemented. In other words, a set of acceptance tests forms the specification for the user story. Anything the customer thinks the story needs to support should be specified in one or more acceptance tests.

And here's where the fun begins. Since much of the focus on acceptance tests has been on automating them, there's very little material available on how to write a proper acceptance test. So the developers may get better and better at automating the tests they are given from the customer, but how does a customer know how to write good tests in the first place?

An acceptance test is just a statement about the functionality of the system. It can be specific, or fairly general, as long as it's testable.

Let's say, for example, that Bill Gates needs a new word processor. He writes a couple of stories like: "Need to create and modify text" and "Need to be able to save and load text".

A team of eager developers starts working on the story and they have questions. Does it need to be compatible with WordStar? What sort of keystrokes does it support? How much memory will you need to run it?

Bill gives some basic answers (since he works on site with the team), and they go back and forth in a two week iteration. The developers write lots of unit tests and they all pass. Brilliant!

Now, for the next iteration, Bill gets a little preoccupied with some nuisance lawsuit, and isn't able to spend as much time with the developers. Since they can't really talk to him, they make some educated guesses about the features, and try to keep it simple.

So Bill has asked for some online help in the next iteration. Our cheerful developers build a maniacal animated paperclip, which certainly fulfills the high level story. Millions of innocent people are made to suffer needlessly.

What if Bill had just written some acceptance tests to clarify things? How about:

1. "When I type F1, the main index of help should appear on top in a separate window."

2. "When I have a word selected and type F1, the definition of the word should popup if available."

3. "Under no circumstances should online help use any cute, animated, or otherwise demonically possessed metallic office supplies."

So take the sum of these acceptance tests (as documents or sentences, not necessarily as executable code), and put some fancy headers on them, and maybe some pictures, or even a couple of throw pillows, and you've got yourself a nice looking functional spec.

Now, if the developers want to, they can automate some of these for regression testing, and to get the warm fuzzy glow of green lights. And the next time someone asks, "Why don't we add a paperclip for online help", the team will rise as one to defend the customer, using the acceptance tests as objective evidence, not just their collective memories.

The key thing is for the acceptance tests to come from the customer (or customer representative for shrinkwrap products). The tests can tell you what the system should do, and what it should not do, but still leave room for creative solutions, intuitive interactions, and elegant architecture.

So are stories combined with their acceptance tests the agile equivalent of a functional specification? Well, in the spirit of agile philosophers everywhere, if it works for you, who cares what you call it?

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams