Agile Principle #4: Agile Requirements Are Barely Sufficient
by Kelly Waters
Agile development teams capture requirements at a high level and on a piecemeal basis, just-in-time for each feature to be developed.Agile requirements are ideally visual and should be barely sufficient, i.e. the absolute minimum required to enable development and testing to proceed with reasonable efficiency. The rationale for this is to minimise the time spent on anything that doesn’t actually form part of the end product.
Agile Development can be mistaken by some as meaning there’s no process; you just make things up as you go along – in other words, JFDI! That approach is not so much Agile but Fragile!
Although Agile Development is much more flexible than more traditional development methodologies, Agile Development does nevertheless have quite a bit of rigour and is based on the fairly structured approach of lean manufacturing as pioneered by Toyota.
I personally believe Agile Development teams can build better products if they have a reasonably clear idea of the overall requirements before setting out on development, so that incorrect design decisions don’t lead the team down dead ends and also so a sensible investment case can be made to get the project funded.
However any requirements captured at the outset should be captured at a high level and in a visual format, perhaps for example as a storyboard of the user interface. At this stage, requirements should be understood enough to determine the outline scope of the product and produce high level budgetary estimates and no more.
Ideally, Agile Development teams capture these high level requirements in workshops, working together in a highly collaborative way so that all team members understand the requirements as well as each other. It is not necessarily the remit of one person, like the Business Analyst in more traditional projects, to gather the requirements independently and write them all down; it’s a joint activity of the team that allows everyone to contribute, challenge and understand what’s needed. And just as importantly, why.
XP (eXtreme Programming) breaks requirements down into small bite-size pieces called User Stories. These are fundamentally similar to Use Cases but are lightweight and more simplistic in their nature.
An Agile Development team (including a key user or product owner from the business) visualises requirements in whiteboarding sessions and creates storyboards (sequences of screen shots, visuals, sketches or wireframes) to show roughly how the solution will look and how the user’s interaction will flow in the solution. There is no lengthy requirements document or specification unless there is an area of complexity that really warrants it. Otherwise the storyboards are just annotated and only where necessary.
A common approach amongst Agile Development teams is to represent each requirement, use case or user story, on a card and use a T-card system to allow stories to be moved around easily as the user/business representative on the project adjusts priorities.
Requirements are broken down into very small pieces in order to achieve this; and actually the fact it’s going on a card forces it to be broken down small. The advantage this has over lengthy documentation is that it's extremely visual and tangible; you can stand around the T-card system and whiteboard discussing progress, issues and priorities.
The timeframe of an Agile Development is fixed, whereas the features are variable. Should it be necessary to change priority or add new requirements into the project, the user/business representative physically has to remove a comparable amount of work from scope before they can place the new card into the project.
This is a big contrast to a common situation where the business owner sends numerous new and changed requirements by email and/or verbally, somehow expecting the new and existing features to still be delivered in the original timeframes. Traditional project teams that don't control changes can end up with the dreaded scope creep, one of the most common reasons for software development projects to fail.
Agile teams, by contrast, accept change; in fact they expect it. But they manage change by fixing the timescales and trading-off features.
Cards can of course be backed up by documentation as appropriate, but always the principle of agile development is to document the bare minimum amount of information that will allow a feature to be developed, and always broken down into very small units.
Using the Scrum agile management practice, requirements (or features or stories, whatever language you prefer to use) are broken down into tasks of no more than 16 hours (i.e. 2 working days) and preferably no more than 8 hours, so progress can be measured objectively on a daily basis.
One thing I think should certainly be adopted from PRINCE2, the very non-agile project management methodology, is the idea of making sure all items are deliverables rather than activities or tasks. You can see a deliverable and “kick the tyres”, in order to judge its quality and completeness. A task you cannot.
See also:
10 Key Principles of Agile Development
What are User Stories
Writing Good User Stories
28 March 2007 01:02
With Agile Model Driven Development (AMDD), see http://www.agilemodeling.com
/essays/amdd.htm , we suggest that you do a little bit of high-level modeling up front as Kelly suggests. To get the details you model storm on a just-in-time basis, thus ensuring that you only invest time in modeling the requirements that you're actually going to implement.
In short, the advice that Kelly provides is pretty much dead on to what the AM community has been promoting for the past six years.
- Scott
1 April 2007 17:25
This looks like another step around the circle. Pretty soon, we will be back where we started with "non-agile" development.
Let's look at the well-used analogy of building a large office building.
Obviously there is quite a bit of planning that has to be done before you start construction. In fact, if you look at most projects in the real world, they work the same way.
It is only with so-called "agile" development that we think we can get something for free.
But it is a lie.
For even if you have everyone on your team that can build skyscrapers in their sleep, THIS PROJECT is not the same as the last project. It means a lot of planning and communicating has to be done to get all the experts on the same page for the current project. You don't get to write a few stories and then just jump in your heavy machinery and build the building. Unless you want to build something horrible.
In many ways, "agile development" is about ultimate job security. There are no real requirements, no real specifications, nothing except some ad-hoc workflows amongst a specific group of individuals. If you want bug fixes or a new version, you are beholden to your "agile" developers.
Maybe it should have been called "crafty development". A little honesty wouldn't hurt, would it?
1 April 2007 20:09
Reply to "no snake oil for me please"...
Not sure if you actually read my post? I certainly didn't advocate jumping straight in. I was advocating high-level visual requirements at the outset, and defining requirements on a just-in-time basis per feature rather than all up-front.
Unlike a building, software can evolve...
Kelly.
20 July 2007 16:31
response to "no snake oil".
It's people like you, who think that developing software is like developing a building, that lead us to using the waterfall method.
The reality is that developing software is nothing like developing a building. The waterfall approach is, and always has been, a square peg in a round hole. As for "ultimate job security" taking 12 months to finish a project that can be completed in 6 by over analyzing and over documenting sounds like ultimate job security to me.
23 August 2007 17:09
RIP (Rapid Iterative Prototyping) uses visual guideposts along the way as well... and may be "Agile" but I am becoming more and more convinced that "Agile" is a catchphrase more than a discipline.
24 August 2007 06:55
Yes, you're right. "Agile" is not a discipline. It's a philosophy. A set of principles and values. A broad approach.
Like all things in life, as this broad philosophy exists, it needs a name. It needs a name so we can differentiate the approach from the more traditional (waterfall) approach to development, i.e. analyse, develop, test, etc.
If you want to call that name a "catchphrase" that's fine, but the term seems to undermine the fact that there is such a thing as an "Agile" philosophy.
Agile *disciplines* are those methodologies that materially support these philosophies, principles and values. For instance Scrum, XP and DSDM, etc. "Agile" in itself is not a discpline.
11 September 2007 13:49
Although I see tremendous value in close amongst team members in developing software, I wonder how the Agile Methodology allows for the passing the knowledge of how the system works without the documentation in specifications. My reservations about the Agile Method is that someone has to go back later and figure out what was done two or three years back to make feature 'a' work the way it does. Without documentation a systems analyst has to spend more time to figure out how feature works. I am sure others who work in an IT shop will find this true. We don't develop software for a large potential consumer audience, we develop software that needs to be used by itnernal users as well as an existing client base.
5 November 2007 21:30
You are 100% right! Currently I am trying to read thru the functionality and come up with a AS IS document that can be ratified by the Business User, as the current IT group take the AGILE very convenitently to code and forget the document part!! Pathetic!!
6 November 2007 08:07
A couple of points...
Firstly, I have worked on may waterfall projects where the spec is barely a good reflection of the finished system by the end of the project, and where commercial constraints prevent us from having the time to go back and update it all. In this case, having a document that is believed to be true and accurate is potentially dangerous and misleading. As a consequence developers learn not to rely on it and base their decisions on the code anyway. I do accept, however, that the documentation can provide some useful context, as long as it's not taken as gospel.
Secondly, the above comment is yet another comment that suggests you didn't really read my post and that you'd formed your own view before you read it. I stated that requirements *are* captured. It's just that they're lightweight and visual, e.g. wireframes/storyboards, at the outset, and details are captured per feature as you go. Why couldn't these feature documents/use cases/user stories, (or whatever you're using) be kept together and provide the same context as you'd have got if you'd written it all up front? The only difference is, writing them as they are needed and not all at the beginning many months before they are developed, they're more likely to be in line with the finished software.
Kelly.
4 January 2008 18:21
re: no specifications - the idea is that you end up with 'executable specifications'. Ideally these are still written in such a way that the majority of stakeholders will understand them. Executable specs have the advantage that the product cannot work without changes to them (assuming you write them in the first place) whereas a word doc gathering dust somewhere may no longer represent what *is* happening. For examples see http://www.concordion.org/ FIT/Fitnesse and API documenting such as Sandcastle
18 November 2008 21:02
There are trade-offs for each approach, and I have in the past debated the defense of each approach. The ultimate factor in determining how well each approach applies is the acceptance of the company for which you are developing software, and the committment from that company to adhere to one approach or the other. If you are in complete control, then this discussion would be invalidated. There are companies who take comfort in "waterfall" because everything is explicitly measurable, and contracts are in place that provide an explicit agreement for the deliverables. Other companies who have trusting entities, good relationships and follow the same mantra of "the best possible software in the best possible time" and are not under the pressures that waterfall traditionally brings to the table are more accepting of the unknown(s) and are usually more in favor of the ability to change directions more quickly. Unless you are working for the government (DOE, DOD), etc., I have yet to see a development shop where waterfall or agile are followed in such a rigid manor that you end up with executable specifications or the agile requisite of change on a dime. Ultimately the tolerances of the company will decide the process.
22 March 2009 18:25
Even when the requirements are written up front, people still write user manuals. So why do both?
What we need is an agile methodology that allows for THE ENTIRE PRODUCT, and that includes the user-training material, to be delivered on schedule. Then folks cannot complain later that functionality is not documented.
I think this precludes an old-fashioned user manual, and requires creative people in the documentation community to come on board.
We need to think through some kind of knowledge web that can capture the changing requirements at a user level and still be right at the end.
21 August 2009 12:50
I agree with no snake oil with one important difference: what programmers build are the skyscraper's blueprints. The compiler is the one building the skyscraper.
That being said: blueprints can evolve. However, once the compiler or the builders set them in stone, the acutal installed program/skyscraper cannot change anymore (unless rebuilt/reinstalled).
What we are arguing about is a methodology to make the blueprints.
Car manufacturers make many sets of prototypes and blueprints before they get to the final version. Archtiects and civil engineers less so - they test each piece individually.
But kitchen appliances makers do little of either. They may make a few models, but for them it is essentially a talented industrial designer designing something smart.
IMO, it's more or less the same with software. It all depends on what precisely we are doing.
Now, there are only very few skyscrapers designed each year, when compared to car models, and even car models there are few a year, when compared for instance with coffee makers - a coffee maker being one of the more complicated kitchen appliances. While the skyscraper designers may need an agile process, because the costs caused by them iterating several times over the whole design are neglectable when comparted to the benefits the skyscraper will bring in, somebody designing and building a custom kitchen furniture for a new house will probably not get financing for doing the design ten times over, with three prototypes thrown in between. Therefore, agile is less of a choice there. Besides, there are highly skilled architects and civil engineers working at the plans for the skyscraper, and possibly just a carpenter working by the advice of an interior designer furnishing the kitchen, so probably there won't be the skills in place to try out several variants, besides the customers not wanting to pay for more than just the minimum cost required to get the job done.
Nevertheless, all that agile methods advocates talk about are skyscraper plans. Which is OK, as long as they don't try to get me buy into agile methods while I'm doing my custom intranet database interfaces for paying customers.