Ellen Gottesdiener

“Business analyst” is not a distinct role on Scrum or other agile teams. And yet, the goal for the team—to deliver high-valued product needs—requires strong business analysis skills. Ellen Gottesdiener and Mary Gorman describe the vital analysis work needed reach the goal, regardless of role.

When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.

Sometimes, an ineffective meeting can be more damaging than no meeting at all. But, if you're not the person in charge of facilitating the meeting, how can you help keep the group and the meeting in line? In this article, Ellen Gottesdiener offers some suggestions for both facilitators and non-facilitators that may help ease some of your meeting frustrations.

Requirements risks are among the most insidious risks threatening software projects. Whether it is having unclear requirements, lack of customer involvement in requirements development, or defective requirements, these troubles are a major culprit in projects that go awry. As requirements expert and agile coach Ellen Gottesdiener explains, agile practice can go a long way in mitigating those risks.

In part 1 of this article (published as a weekly column on May 22), Ellen Gottesdiener discussed the need to adapt your requirements practices to your product and project. In part 2, she explores additional issues for tailoring requirements development and management.

Should your requirements practices embrace the change-driven approach of agile methods--lightweight models, minimal documentation, and little process? Or should you take a risk-driven approach--robust models, careful validation, and rich documentation? In this two-part weekly column, Ellen Gottesdiener explains that you should tailor your requirements practices to your project and product.

This template for a requirements workshop includes preparation tasks and, a place for listing workshop tools and participants.

There's no standard formula for requirements workshops. Each project, business situation, and group of people will combine to make each workshop unique. Preparing for the requirements workshop requires collaboration. It permits you to tap into the collective wisdom of all of the project stakeholders. In your workshops, participants are active, engaged, committed, and task-oriented. A well-run workshop builds trust and mutual understanding among all the participants. Workshops are not new, but are proven best practices in software development. They can go a long way not only in product delivery, but also in building a "jelled" team.

This template is used for guiding a debrief (retrospective) of a requirements workshop. The facilitator can replicate this template on a poster or wall and guide the discussion to "fill up" each slot in the template.

Reviews can be effectively integrated in your workshops, helping participants to create higher quality deliverables. Integrating reviews in your requirements workshops also helps participants to more fully explore how requirements relate to each other. This brief document provides you with a list of steps to employ before, during, and after a collaborative workshop to make best use of reviews.

A brief overview of how to integrate reviews into your requirements process while iteratively delivering your requirements. A figure is provided as an example. Different requirements models are shown as being created in stages and various review types are used to check their quality.

A brief overview to reviews, inspections, and walkthroughs--an essential technique to increase quality and enhance team collaboration.

This use case template will help you keep track of changes and the disposition of use cases during a requirements workshop.