5 February 2010

How do you manage large projects with Agile?

As a business analyst, I spend a lot of time focusing on gathering good requirements.  Once I have a high level set of requirements, I work to refine the requirements to the point where the developers will have enough information for design and implementation of the application.  Everyone has a method for achieving this requirements definition process but I would hope at the end they have a fairly robust set of requirements from which to work.

This is where I find myself at a loss when working in an Agile environment.  I know that only the user stories that are being worked in the current sprint are expanded.  These user stories encompass a subset of requirements for the project.  But at what point do those of you doing Agile find the simple 3x5 cards become unwieldy?  At what size project do you start to say "Maybe we need something to keep track of these user stories"?  And more importantly, where do you turn when you reach that point?


  1. First up, I'm not an Agile practitioner, so I can't say how it is supposed to be done by the book. I do appreciate many of the Agile principles and think that if Waterfall happens to be what fits at your company, you can still learn a lot (not to mention implement some) of the Agile principles.

    What I would do is create a cross-reference rolodex, probably in some kind of computer program. I would find an app that allows cards to be created as images, scan in the customer created cards, then link them all together. If you can add in custom metadata, even better. You can create custom fields for items such as card creator, sprint #, etc.

  2. Hello again,

    I am actually working with a client that wants to do requirements first, and then develop whatever is the best way for the project, including Agile. The sync point we are looking at is the equivalency of a step in a business case with a user story. This has some promise becaue of the way we do business use cases, it might not work with just any use case...but I will likely report on how it goes down the road.

    Also, i found a site on agile the other day that spoke of organizing related user stories in groups it called a "theme". And if needed, you may group multiple themes into an "epic". Certainly the terminology is appealing, but did not see much on how one defined such groupings. Of course, the name of this site escapes me now, so I may have to search it out.

  3. Two sites that get into the difference between story, theme epic are;

    Dan North - What's in a Story, and
    Agile 101 - The difference between..."

  4. We use Epics, Minimal releasable features (MRF's), and user stories.

    Each user story ties to a feature, each feature ties to an epic.

    This way all small user stories have to tie back up to higher level goals. Usually the epics are the business problem/goal you are trying to solve.

    We use a software tool (Rally) to manage the backlog, so we can easily move/group stories and report on the effort spent on the various Epics, etc.

  5. At some point I started using Feature Lists from Feature Driven Development for all projects. A good overview can be found at Extending FDD for UI
    (browse to The Solution - Feature Driven Development). On my projects Feature List accompanies "main" requirements documentation be it set of user stories or traditional FRS.

    I try to get each feature described such that when asked "Is this feature implemented?" you can answer either Yes to No. Such Feature Lists helps a lot to ensure everyone reads user story the same way and it is great way of tracking design, tests and actual product functions back to requirements.

    I believe that project can not be small enough for you not to want to track requirements no matter what form of requirements documentation is used. Even when no formal requirements documentation is developed I create Feature Lists to make sure we do what was discussed on meetings.