All About Agile | Agile Development Made Easy


Agile Principle 4: Agile Requirements Are Barely Sufficient

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 project 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.

Kelly.

See also:
10 Key Principles of Agile Development
What are User Stories
Writing Good User Stories

Home



17 Responses to “Agile Principle 4: Agile Requirements Are Barely Sufficient”

  1. Scott W, Ambler says:

    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

  2. no snake oil for me please says:

    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?

  3. Kelly Waters says:

    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.

  4. Anonymous says:

    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.

  5. Josh Milane says:

    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.

  6. Kelly Waters says:

    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.

  7. Kevin says:

    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.

  8. ananth says:

    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!!

  9. Kelly Waters says:

    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.

  10. pkr says:

    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

  11. Eddie says:

    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.

  12. JObermark says:

    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.

  13. A_flj_ says:

    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.

  14. mrt says:

    Hmm interesting piece, I for one abhor too much documentation, but support the idea of having enough documentation to deliver a quality product. Honestly, I’m still getting to know AM.

    What concerns me is that some agile dev teams would conduct interviews, write a user story, which they don’t validate, go away, come back w/ the software product. And claim that agile has enabled them to define the actual scope based on the user stories they collected and develop the final product as delivered.

    Is this how agile is supposed to work, or this team got it wrong big time?

  15. Kelly Waters says:

    Hi mrtawanan! To be honest I’m not sure if I follow your question. As far as I’m concerned, no development methodology, whether it’s an agile methodology or a more traditional one, assures you that you are developing the right thing, as they are processes for how to develop or how to manage development, rather than what to develop.

    On the other hand, the fact that agile teams develop products incrementally, deliver frequently and work in short iterations mean that the feedback cycle is very short, giving the team the chance to adjust to new information more regularly. This ability to respond can make it more likely that you’ll deliver the right product in the end, even if it’s not exactly as it was originally envisaged.

    Kelly.

  16. Suresh Balakrishnan says:

    There is no absolute waterfall model and there is nothing we can call pure agile model. What one starts as waterfall model, spirals and eventually could come close to agile. This is more so in software development where requirements progressively elaborate mainly because it is difficult for most people to imagine the final product in absolute detail. One could do that well with a building construction. Collection and representing requirement as wireframes and storyboards is very common in multimedia projects though many of them may not know that it is part of agile philosophy. But you can’t do with just the visual always. Depending on the requirement, one may need structured and formal documentation. Imagine an Enterprise application that connects with many other. You absolutely need a design that is well thought out, one that will last. Knocking off one functionality and putting in another may not be as simple as it sounds. What about impact? Whatever one calls it, one needs to plan as much as the project needs and as much as ones budget permits. Agile is not about listening to the requirements and punching the code. Neither is the Waterfall model about planning for eternity. Use these philosophies intelligently and as your specific situation demands. Use the wrong was and Agile will become fragile and Water fall will be a big fall. Cheers !

  17. Jake says:

    “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 – See more at: http://www.allaboutagile.com/agile-principle-4-agile-requirements-are-barely-sufficient/#sthash.TJMoLzcy.dpuf

    The only problem I have with this statement is the problem with having to read the code because the design documentation is bad. If features are always apparent and requirements changing rapidly, how does one recover when having to make changes in the future after the project is completed? It becomes a maintenance nightmare because in order to make fixes or add new features, one has to re-read the code, and if the project is sufficiently large, this may take more effort than just reading documentation and knowing exactly where the change or addition is needed.

Leave a Reply

What is 2 + 8 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)