Success with Requirements

Volume 3 :: Number 2 :: 2009
ISSN: 1936-3583

Welcome to our Newsletter

I am passionate about agile requirements. Recently, when the IIBA asked me to conduct a webinar for its membership on the topic, I eagerly responded "yes!" During the webinar there was only time to to answer a few of the many questions posted by the attendees. Given the keen interest, I thought it would be helpful to answer them all and share them with you in the next several EBG eNewsletters.

I hope you find this Q&A format informative. Please share your thoughts, and if you have additional questions, send them to me and I'll do my best to respond.

~ ellen

Ellen Gottesdiener,
President and Principal Consultant
EBG Consulting, Inc.
http://www.ebgconsulting.com

In this issue:

Public Offering of Agile Requirements Training

Agile Business Analysis: Webinar Q&A (Part I)

Upcoming Events

Resources of Interest

Reader eLearning Discount

Archive Issues

Public Offering of Agile Requirements Training

We are pleased to announce the June 16-17th public offering of EBG's Agile Requirements: Collaborating to Define and Confirm Needs in Cincinnati, Ohio, USA. Ellen Gottesdiener will be your instructor in this interactive course that shows you how to define and prune your product backlog items, collaborate to develop requirements, adapt your requirements practices, and clarify your business needs. Register here or email us for more information.

Agile Business Analysis: Webinar Q&A (Part I)

Following is Part I of the Q&A for the January 20, 2009 webinar "Agile Business Analysis" presented to International Institute of Business Analysis (IIBA) members. Click to read a brief description of this webinar).

To view the webinar, click here (member login required). Non-IIBA members wishing to view the webinar can email us and we will provide you with access.

Agile Modeling

Q: What modeling techniques are used in an agile project?
A: User stories or scenarios are the primary "model" used by agile teams to represent user requirements for each iteration. User acceptance tests or very lightweight use cases can also be used to represent requirements. These can be supplemented by low-fidelity analysis models, such as a data model, a context diagram, a state diagram, and the like.

Forms of Agile

Q: Ellen mentioned scrum as a "form of agile." Are there multiple forms of agile?
A: There are multiple methods or styles of agile. Some examples are DSDM (dynamic system development methodology), scrum, FDD (feature driven development), lean, crystal, XP (extreme programming), and UP (unified process). All share the values and principles of the Agile Manifesto.

Timing of Analysis

Q: Is this type of analysis a subset of a bigger project-something that kicks in toward the end of the project?
A: Analysis is continual on agile projects. At any given time, you analyze small chunks of about equal-sized requirements for delivery in short timeboxes (not the entire product up front). On large products you need some up-front analysis to understand scope, create a high-level product roadmap, and make smart choices about which requirements to deliver early on. On large products, this analysis is sometimes done in an initial setup iteration (often called "iteration zero").

Work-Ahead Requirements Analysis

Q: Does the "ready backlog" need to have complete requirements for each project in the backlog-that is, ready requirements? So do you create the requirements before you actually select them to be included in an iteration?
A: Only backlog items that are going to be pulled into an iteration need to be "ready." In that way, you do not waste time working on non-immediate deliverables, something that may require relearning nor do you run the risk of using precious resources on items that might change. Your backlog contains items at a high level. You analyze requirements for items selected for an iteration only when the team is about to work on them.

Q: In an agile process, how far ahead should requirements be done ahead of development?
A: You will typically conduct work-ahead analysis for one, and possibly two, iterations.

Q: Do business analysis deliverables need to be prepared before the iteration starts?
A: You may need to have some analysis artifacts on hand during iteration planning so that the team can size and task out a given backlog item.

Testing

Q: When does the testing (system and user acceptance) start in an agile project?
A: Testing takes places within each iteration.

Timing and Up-Front Analysis

Q: To design a product thoroughly, the project team needs to set out the product boundary. Supposedly, this needs a lot of analysis up front to get a whole picture of the product, and cannot be agile. Could you comment on this?
A: To define a big view of the product architecture, plan for releases, and prepare the organization to accept those releases, agile teams need an understanding of product scope and high-level requirements.

There is value in some up-front analysis on large, complex products. However, this should not require "a lot" of analysis. In my experience, an efficient way to do this is to use facilitated workshops to deliver, along with the vision, a set of interconnected scope-level requirements models that allow you to see the big picture as well as interdependencies. These models become critical input, along with a technical and marketing roadmap (if appropriate), to creating a product roadmap.

When Not to Use Agile

Q: Are there any circumstances where agile is not recommended?
Q: Are there any types of projects that are not a good fit for agile?

A: You should not use agile...

When your product requirements are entirely clear and understood by all stakeholders up front.

When business customers do not want to be involved in the product development process except briefly, at the start.

When there is no flexibility in reporting structures and therefore a cross-functional team cannot be formed and allowed to self-organize. When management will not give up command-and-control management, will not consider adapting documentation practices, or will not allocate money and time to allow teams to learn through training, coaching, and patience.

When you cannot form a team willing to learn and change.

Next month: Agile Analysis Q&A Part II

In next month's issue of "Success with Requirements," I'll address questions on user stories, doneness, documentation, rework, and more. Stay tuned!

Webinar Brief Description

Misconceptions abound about how agile projects conduct analysis, and whether they even do analysis. In practice, agile projects rely on business analysis as the basis for planning, development, and delivering business value. Join us on January 20, 2009 when requirements expert and agile coach Ellen Gottesdiener shares the exciting and challenging ways agile projects leverage business analysis to deliver business value sooner.

Key Learning Points:Learn how analysis really works on agile projects

Understand the tactical and strategic activities of agile business analysis on agile projects

Gain an appreciation for the competencies needed to do business analysis work on agile projects

Upcoming Events

1. Ellen Gottesdiener will be presenting to the Melbourne, Australia and Wellington, New Zealand IIBA chapters in March 23 and 26, 2009.

2. Ellen will be keynoting, presenting a mini-tutorial, and participating in an international speaker panel at the Software Development 2009 Conference in Melbourne, Australia and Wellington, New Zealand March 24 and 27, 2009.

3. Ellen will present at Boston Agile (Agile Project Leadership Network, APLN) in Waltham, MA, USA on April 29, 2009.

4. Mary Gorman will be keynoting and presenting a talk at the Central Iowa IIBA chapter's Business Analysis Development Day on May 1, 2009.

5. Ellen will present at the PMI Mass Bay Chapter's Professional Development Day in Waltham, MA, USA on May 2, 2009.

6. Ellen and Mary will be conducting workshop sessions and symposium talks at ProjectWorld/BusinessAnalystWorld in Toronto, Canada May 10-15, 2009.

Resources of Interest

Each month we provide a few resources we think are worthwhile. Following are resources related to this month's Q&A on agile requirements.

Scott Ambler has many good writings on agile modeling. One of my favorites is his description of "Just Barely Good Enough Models and Documents."

In their presentation "The Yawning Crevasse of Doom" (video, no slides), Dan North and Martin Fowler discuss closing the communication gap between developers and customers or users. Martin describes a wonderful analogy about agile analysis - the ferryboat or bridge. Listen to their engaging presentation to learn more.

Kelly Waters has created a compelling presentation in his blog, "10 Key Principles of Agile Software Development." Principal #1 is Active User Involvement is Imperative (this has been the first principal of the original form of Dynamic System Development Method, DSDM - the grandmother of agile/iterative methods). The term "users" can be misleading and imply other stakeholders do not need to be actively involved or act as product owners or champions. Despite that, the points Kelly makes on this page are valuable. Also note Principle #4 is "Agile Requirements are Barely Sufficient" in which Kelly points out that "(i)deally, 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."

Reader eLearning Discount

For your Success with Requirements eNewsletter subscriber discount (10%) on our 8-course self-paced eLearning training curriculum, Foundation for Requirements Development and Management use code: FRSWR04 when you register here. This curriculum is endorsed by the IIBA and earn 24 CDUs.

Archive Issues

Visit our archive to read our prior issues.

Publication & Reprint Information

I invite you to reprint material from Success with Requirements in other electronic or print publications provided 1) the following copyright notice is used, "Written and edited by Ellen Gottesdiener, copyright EBG Consulting, Inc., [year]. All rights reserved." and 2) a link to http://www.ebgconsulting.com/ is included in the credits.

Please send us copy of the publication that includes our reprint, along with a cover note referencing that it is a reprint.

Success with Requirements is a trademark of EBG Consulting, Inc.