5 February 2010

How do you manage large projects with Agile?

Posted by Janet Rolsma
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?
Labels: ,

6 comments:

  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.
    ReplyDelete
  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.
    ReplyDelete
  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..."
    ReplyDelete
  5. 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.
    ReplyDelete
  6. 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.
    ReplyDelete

Subscribe to: Post Comments (Atom)

Popular Posts

  • What is Project Scope? What should it be?
    I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
  • User Story Template
    Due to popular demand I have aggregated some information on User Stories and created a simple template.  If you feel this would be useful to...
  • Change Request template
    Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
  • BCS forum on "Making Projects Work"
    You've heard many reasons why project fail.  Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
  • PDMs - Precedence Diagram Method
    The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
  • Snowbird; Agile 2011 discussion on the BA
    In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
  • Email, Whiteboards and Well-Caffeinated Wits
    This is a guest post by Jeff Hobbs.  Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
  • 7 Requirements Analysis techniques
    In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
  • An Introduction to Stakeholder Management
    The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
  • The V-Model: Table of Contents
    I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...