Rhetoric teaches us that the answer is probably yes. However I feel that we would no longer relate to the vast majority of Agile success stories.

I think that my upper management read the benefits column of an Agile process but forgot to read about the requirements or how successful Agile businesses got there.

  • 11
    How can you build software without use cases or tests? To me, that says you have no users, no requirements, and no ability to verify or validate any aspect of your system.
    – Thomas Owens
    Aug 3, 2011 at 18:19
  • 1
    @Thomas maybe i should abandon ship...
    – Eric
    Aug 3, 2011 at 18:25
  • 1
    If you honestly don't have a requirements specification and some kind of unit, integration, system, or acceptance tests, yeah, I would say so.
    – Thomas Owens
    Aug 3, 2011 at 18:26
  • 2
    @Thomas - you would be surprised :) Often there are requirements as to what the system should do, but no use cases or tests (my experience most of the time) to actually put things into perspective or verify that it works. Aug 4, 2011 at 14:55
  • 1
    @Wayne Use cases can be derived from functional requirements. Use cases by themselves aren't necessary, but if you can't derive them, that's problematic and indicates you don't understand who your users are and what your software is supposed to do for them.
    – Thomas Owens
    Aug 4, 2011 at 15:25

5 Answers 5


Is it possible to be agile without use cases and tests?

Not in my opinion No. See wiki for full definition, but here is the opening:

Agile Software Development is a group of software development methodologies based on iterative and incremental development...

Does this mean you are writing unit tests with NUnit; mocking with Rhino or Moq? No, but it will certainly be more difficult to produce solid, stable applications on time (late projects will certainly hurt the budget more than time spent writing use cases and tests).

Additionally, without unit tests, it is really hard to be agile - try having a requirement modification mid-project and hunt down everywhere you have to make changes ...

Agile development, IMHO, must be incremental. Without properly defined use cases and tests, development cannot be truly agile.

I have found that agile development keeps projects focused on the requirements.

  • 3
    It's not your opinion that agile must be incremental. It's a fact that agile must be iterative and incremental.
    – Thomas Owens
    Aug 3, 2011 at 19:15
  • @Thomas - I wanted to emphatically say no. I felt that deferring to 'my opinion' left less to be argued by nay-sayers. ;)
    – IAbstract
    Aug 3, 2011 at 20:34
  • 3
    Anyone who says agile isn't incremental and iterative isn't a naysayer. They are just wrong. There isn't that much that's so cut and dry in software (especially when you get into process and methodology), but that's one of them.
    – Thomas Owens
    Aug 3, 2011 at 20:38

I think that my upper management read the benefits column of an Agile process but forgot to read about the requirements or how successful Agile businesses got there.

This is a very common problem with Agile...

Because Agile is so light on rigid processes, in a lot of shops it becomes an excuse for sloppy cowboy coding - a kind of methodology which looks like Agile on paper, but is really no methodology at all.

My last workplace was exactly like this. It was basically cowboy coding. The only saving grace was that they had an official Testing department and a decent bug tracking system - so at least the iterations on development of new features were relatively formalised. But in all other aspects, Agile was hardly implemented properly at all. 90% of the time you were just hacking away at some completely undocumented code.

At the end of the day, I think the biggest issue here is the good old "If you're not typing, you're not working" syndrome. A lot of non-technical managers just don't seem to get that there is more to programming than sitting at your desk banging away at code. And these are the aspects of Agile which often get neglected. eg, At my last workplace it seemed to be a bit of a taboo for programmers and BAs to sit together for a long time discussing something, as if it wasn't "real work". We'd just get a basic description of a feature, implement it, and then it wouldn't be accepted by the client. Repeat. Eventually the entire codebase becomes a hack upon a hack - not to mention that taking the time to refactor is also often not considered "real work" in that sort of environment.


Is it possible to be agile without use cases and tests?

Tests are kind of required if there is to be verification of what was built which to my mind is a typical thing. Not always done but probably 99.999% of the time there is some kind of test done. In doing that test, what is there if not some kind of use case? Even if the test is just to see that it does work as expected, isn't that still a possible scenario of execution, which is how I'd define a use case in a rather liberal way?

Wouldn't the better question be, "How useful is it to be agile without use cases and tests?" To which I'd answer, not very.


Agile is about building a system up in a set of small working iterations. You reevaluate business priorities at the end of each iteration, and figure out exactly what to build next. The use-case is the fundamental currency of agile development, in that each iteration comprises old use-cases and a small number of new use-cases.

If you are able to fully test your system at the end of each iteration, and know that you won't break any previously written code, then you don't need programmed tests. So....you don't need programmed tests....at first.

However, as the system grows, it becomes harder and harder to fully test the system, and it becomes harder and harder to remember exactly what you built a few iterations ago. At that point, you cease to be agile, because testing is too hard because it is not automated and repeatable.


IMHO, the answer is that no one knows what Agile truly is, so, basically you can't get the right answer to an abstract question about abstract thing.

MSF vs. Scrum vs. something else is like comparing apples to oranges.

And depending on the methodology, or better yet, revision of the methodology, the basic assumptions will change.

Some think that Agile is doing the same stuff, but shipping faster. Some think that Agile is really an iterative process with close interaction with customer, where every iteration sees 50%+ of code changes Some think that Agile is waterfall, but without specifications. etc.

So depending on how Agile your Agile is, the question can go either way.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.