Success with Requirements
Volume 3 :: Number 3 :: 2009
ISSN: 1936-3583
Welcome to our Newsletter
In case you didn't see last month's eNewsletter, in January I conducted a webinar on agile analysis for the IIBA. Due to the webinar's time constraint, I couldn't directly answer the many questions that were submitted. So I decided to answer them through this eNewsletter. Part I was in last month's eNewsletter, this month is Part II.
I hope you find this Q&A format informative. 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:
Polish Translation of Requirements by Collaboration
Agile Business Analysis: Webinar Q&A (Part II)
Public Offering of Agile Requirements Training
Recently IIBA-Endorsed Training Offerings
When is eLearning a Good Way to Learn?
 |
| Polish Translation of Requirements by Collaboration |
 |
We're pleased to announce another foreign language book translation (the book is also available in Japanese). Warsztaty Wymagań. Narzędzie zespołowego precyzowania wymagań (Ellen Gottesdiener's first book, Requirements by Collaboration: Workshops for Defining Needs ) is now available in Polish!
The cover is shown here:
|
| Agile Business Analysis: Webinar Q&A (Part II) |
|
This is Part II of the questions & answers generated from the "Agile Business Analysis" webinar I presented on January 20 for International Institute of Business Analysis (IIBA) members. Click to read a brief description of this webinar).
Given the keen interest and volume of questions, I am providing you with written responses to all of questions. For Part I Q&A (published in February, go to our Archives page). Part II follows.
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.
User Stories
Q: How do you decide at what level of detail your story cards should be? For example, should a story card be by screen or by each function within a screen (add, update, delete)?
A: Stories for each iteration should be about the same size. They should contain enough detail for developers to build the code and test them (including user acceptance tests). They should be detailed enough for the product owner (customer) to confirm that the story was built according to the customer's completion criteria. You may include low-fidelity screen sketches but generally they should not show each UI (user interface) action. Also, remember that a single story will not incorporate an entire set of CRUD (create, read, update, and delete) activities. It will be much smaller.
Doneness, Completion Criteria, and Small Requirements
Q: What's an example of completeness criteria?
A: Examples of completeness criteria for a story include user acceptance tests, a list of input and output data, and a list of pre- and post-conditions.
Q: Please share some examples of tight and precise agile requirements.
A: These are stories, along with other stories of roughly the same size, that (1) can be completed within a single iteration and (2) have very clear completion criteria.
Here's an example of a single story: "As an IIBA member I want to find webinars provided exclusively to IIBA members so that I can increase my awareness and skills." Along with that simple story you define criteria and conditions; for example, the user is an active member already logged on to the site; the user provides one to three keywords for searching; the user is returned up to 10 webinars, which include the link, title, date, and presenter. To make the story even more precise and to invite discussion about business rules, data attributes, and interfaces, you should also define specific data that would be used as input, along with the expected results of acceptance testing on that story.
Analysis Spike
Q: Could you give another example to clarify "spike analysis"?
Q: Are "spikes" valid in scrum?
Q: Can you explain a "spike" a little more?
A: A "spike" is an experiment, something you do fast to learn and reduce uncertainty. The term was originally associated with XP (extreme programming), but it has become part of the agile vernacular.
For example, an analysis spike might be a story that incorporates a small amount of user or compliance documentation in order to test whether the documentation is sufficient for all the other stories in the backlog. Another analysis spike might be a story that lets you hunt down which data file, among multiple possible ones, is the best source to use for a large set of attributes that reside in multiple application databases.
Documentation
Q: When you talk about "lightening" the amount of documentation that you produce, do you produce enough documentation to support the product once it is implemented?
Q: What kind of testing documentation is prepared in an agile project?
Q: What is the recommended approach to documenting business requirements? Is there a recommended format or template for documenting requirements?
A: Documentation should provide some value to a consumer of that documentation - developers, maintainers, testers, help desk staff, marketing or training personnel, and so on. Each project may have unique needs for documentation, so be prepared to tailor documentation to meet the consumer's minimum needs. I often suggest conducting an analysis spike to experiment with how best to handle a specific project's documentation. Do this in an early iteration.
Note that user acceptance tests can be used to represent requirements, serve as documentation, and simplify traceability. This is a "lean" way to handle documentation, because it eliminates redundant versions of information.
For more ideas on ways to lighten documentation, see "YAGNI Your Requirements Documentation."
Rework
Q: Doesn't agile practice introduce rework in the product life cycle? For example, the project team rushes into developing the product without fully capturing (or understanding) the user needs, or even misunderstands the user needs/requirements, and then later needs to spend effort to recorrect what was done in the previous cycle.
A: On agile projects, a customer may learn that items they thought were of value during an earlier iteration are less important. Or, the team may learn that higher-value items built early (to obtain immediate business value) will require technical rework to accommodate additional functionality. (This is called "technical debt," and some teams use good strategies for minimizing it throughout each iteration.) Thus, some rework may be required. However, rework tends to be on smaller pieces of the product than in traditional development.
The agile philosophy is that some rework is inevitable in order to deliver higher-value items early one. Yet ultimately agile will save time and money because you've built the right software instead of spending a lot of time and money specifying and building features that aren't important or don't provide value.
In my experience, delivering items before their interdependent features are completed can cause rework. Many agile teams try to minimize rework (technical debt) by establishing an overall wide-and-narrow understanding of the product's architecture. This view of architecture is based on requirements and incorporates requirements dependencies. It allows customers to make more informed decisions about the trade-offs involved in various delivery sequences.
No agile team should "rush" into development. Agile (done right) is not about hurrying up and going fast but about delivering in an adaptive manner. In other words, you are not agile because you are going fast. Rather, you are going fast because you are agile.
Next month's Agile Analysis Q&A
In next month's issue of "Success with Requirements," I'll address questions on nonfunctional requirements, impact analysis, agile certification programs, mixing agile and waterfall, and more. Stay tuned!
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. On January 20, 2009 requirements expert and agile coach Ellen Gottesdiener shared 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
|
| Public Offering of Agile Requirements Training |
|
On June 16-17th we are conducting a 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.
|
| 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.
7. Ellen and Mary will be conducting workshop sessions and presentations at Project World & World Congress for Business Analysts in Baltimore, Maryland, June 24-26, 2009. You can get a discount by using priority code SPKRM2110EG when registering.
|
| Recently IIBA-Endorsed Training Offerings |
|
EBG Consulting is a Charter Endorsed Education Provider with the IIBA. Our most recent courses to obtain endorsement are:
Agile Business Analysis: A Comprehensive Roadmap to Success (21 CDUs)
Collaborating for Success: Facilitation Skills for Agile Teams (21 CDUs)
Roadmap to Success: Scope Modeling (14 CDUs)
Essential Data Modeling (7 CDUs)
Learn how EBG contributes to the IIBA.
|
| When is eLearning a Good Way to Learn? |
|
When we first began beta testing our flagship requirements foundation elearning course, Ellen shared with Tom Humbarger why we produced this unique offering using a self-paced eLearning approach. Tom later produced a useful blog entry on the best way to learn which nicely portrays our thinking.
|
| 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. Upon completion you will earn 24 CDUs.
|
| Archive Issues |
|
Visit our archive to read our prior issues.
|
| Publication & Reprint Information |
|
Success with Requirements is a trademark of EBG Consulting, Inc.
© 1993-2007 EBG Consulting, Inc. All Rights Reserved.