Writing User Stories:

Agile Requirements Development Process FAQs—Part 2

Q&A from a Webinar by Watermark Learning Instructor,
Marsha Hughes, CSM

TESTING AND QA

Q. When is testing done for iterations based on User Stories and how are defects managed?

A. Ideally, testing for the developed stories is done within the iteration in which they are developed. Testing also needs to include regression testing of functionality developed in previous iterations, which is why automated testing tools help in any iterative approach. Defects should be fixed in the same iteration, if they are discovered then. Defects found after an iteration can be bundled into a “story” and placed on the product backlog and prioritized along with the other stories.

Q. If details aren't captured as acceptance tests, how do you know what is required vs. not as in your example when you have fields to enter? What if you can't show your user anything (i.e. a scheduled batch process)?

A. Remember that the stories are placeholders for conversations with the customer/user—those conversations between the customer/user and the team are ongoing and address questions such as what the data fields should be, etc. If you can't show the user anything on the screen, then perhaps you can demonstrate that the batch process completed successfully.

Q. In the first sprint, do you have user stories to cover some of the infrastructure stuff needed to get the base system working? How does detailed QA testing get done if only write acceptance level tests?

A. The early sprints often need to put some base functionality in place for the later sprints to build on. On a recent project I worked on, the developers created small design specs called mini-specs for each user story—these were 1-3 pages, and included screen mockups and design information, such as database tables. The QA group used the stories and the mini-specs to create the tests.

Q. In more traditional methodologies, I've seen SRS and Functional Specs written to document requirements. These are used by QA for testing, as well as for developers to develop software. Are stories enough for QA to test intended functionality? If not, how does QA know what to test?

A. On a recent project I worked on, the developers created small design specs called mini-specs for each user story—these were 1-3 pages, and included screen mockups and design information, such as database tables. The QA group used the stories and the mini-specs to create the test cases.

Q. Does having the users of the system in the room act as or replace the need for early concept usability testing?

A. It can replace it to some degree, although you might want to include formal usability testing in the iteration prior to a release.

SPRINTS AND ITERATIONS

Q. Is the goal of each sprint to produce a workable product to deliver into production?

A. No—usually the software produced in several sprints goes into a production release. Some teams use a “release sprint” just prior to the release for finalizing the software and doing extensive integration and production readiness testing.

Q. In your experience, what percentage of the user stories are identified in iteration 0 versus percentage that are identified through the remainder of the project? At what point in the story gathering process have you seen the stories entered into a tool like Version One?

A. I would say that 60-70% of the high-level stories are identified early, and the rest evolve as the customer understand the system better by viewing the results of the iterations—they think of new stories, change the priorities for existing stories, delete stories, etc. The product backlog is really very dynamic. If you are using a tool I think it makes sense to create your backlogs in the tool from the start.

Q. How do we know when to stop iterations?

A. Usually projects have a finite budget and schedule, and agile projects are no different. If you have developed all the high priority stories for a product and released it, you could stop then, or continue to build the medium priority stories—it really depends on the project's situation.

TYPES OF PROJECTS

Q. How do we do requirements gathering in large agile projects with distributed teams?

A. Most people who are doing large, distributed agile projects have created sub-teams who are each focused on a portion of the system functionality. The sub-teams need easy access to a customer representative to help them gather and clarify the stories for their iterations—often these customer representatives work with an overall product manager for the project, which helps coordinate the overall requirements. For more details on this topic, I recommend the webinars at this site on agile methods. There have been several on agile methods for large, distributed projects that have been excellent and informative (Note, there may be a small charge for these webinars).

Q. Is agile appropriate for a heavily regulated project, such as in the medical field?

A. Agile methods have been used for all sorts of projects, although I haven't personally been involved in a heavily regulated project.

Q. Are there types of projects that you recommend using agile—and conversely are there types of projects that you would not recommend using agile with? When communicating the project budget to stakeholders, is there ever a time that you have the total project cost or do you estimate each iteration as it is developed?

A. If you are just starting to use agile methods, I would recommend starting with a small, co-located team and customer representative to get some experience with the method in its purest form. Using agile methods is more challenging in large, distributed environments, but it can be done successfully—visit this website for an excellent webinar on this topic.

You can estimate the total project cost based on the number of releases, iterations within the releases, lengths of the iterations, and project team size. See my further comments on estimation above.

Q. Sometimes Waterfall is helpful because you get to see the whole scope of what the project will be. This can help IT develop and determine the correct architecture needed since they know the entire scope. How is IT affected if they make some architecture judgments that won't be applicable as the system grows? Won't this cause more problems having to go back and change the structure?

A. In agile methods, the process of adapting the design and architecture as you learn more about the system is called refactoring. Refactoring is the process of clarifying and simplifying the design of existing code, without changing its behavior. Agile teams are maintaining and extending their code a lot from iteration to iteration, and without continuous refactoring, the code becomes difficult to maintain. I have been on waterfall projects where we had to “refactor” the design and code due to performance problems very late in the lifecycle, and so I think the continuous refactoring approach has merit. Most agile teams make some design and architecture decisions up front, as with waterfall projects, but they realize that they may need to refine and refactor the design as the system evolves.

DOCUMENTATION

Q. What will be the best way to document assumptions in user stories?

A. The best way to document assumptions about a user story is to make notes on the index card, or in the story management tool. That way all the information about the story stays with the story.

Q. In the support of the product after the implementations, is there a problem as a result of limited documentation?

A. Some of the user stories can address the needs of the support users—e.g., “as a help desk user, I need support documentation.” The documentation would be developed during an iteration—probably late in the lifecycle, so it truly reflected the actual product.

Q. How do you handle the fact that there doesn't seem to be much documentation in an Agile environment? What do you use for documentation?

A. For end user documentation, you can write a story such as “as a support technician, I want to be able to reference documentation in order to...”. The story would be added to the product backlog, and the documentation could be developed in one of more iterations. As far as traditional design documentation goes, one project I worked on developed “mini-specs” for each story—each spec typically had a screen mockup, database tables, and other design elements. These were created at the start of an iteration. Basically you can create as much documentation as you need in agile processes, but documentation is not the focus. I have heard someone say that the code IS the documentation, and unless all the documentation for a traditional system is rigorously kept up to date, I think that is probably true to some extent for any system.

About Watermark Learning
Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results.

With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations to be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider.

For more information, contact us at 800-646-9362 or at www.WatermarkLearning.com

© 2008 Watermark Learning, Inc. All rights reserved worldwide. Do not copy, distribute, or present without written permission from Watermark Learning. Published as part of 2008 PMI Global Congress Proceedings - Denver, Colorado, USA