We know listening is important—typically it’s what our stakeholders have to share that we most need to hear when eliciting and validating scope or requirements. At the same time, as business analysts, we cannot be passive flies on the wall.
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.
Release management is a complex function that involves many essential technical tasks that must be completed in a very specific way. At first glance, one might think that Release Management has little or nothing to do with personality and psychology. In the book Configuration Management Best Practices: Practical Methods that Work in the Real World, Bob Aiello and I focused three of our fourteen chapters on the people side of CM. The fact is that people skills play an essential role in release management. Read on if you want to improve your ability to get the job done and achieve success in release management!
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.
An often-cited bugaboo of many projects is scope creep-the unrestrained expansion of requirements as the project proceeds. Yet requirements development is about gaining an ever-growing understanding of requirements. So, isn't scope creep normal? Find out in this week's column as Ellen Gottesdiener explores exactly how to keep scope under control.
Not all requirements are created equal, so to make smart choices about which product requirements you should explore and implement-or whether you should delve into them at all-you need to prioritize them. Many teams do not prioritize properly and waste time specifying requirements that are never delivered. Why spend time and energy on requirements you won't use? In this week's column, Ellen Gottesdiener answers the question by detailing how and when requirements should be dealt with.
As we look to deploy or improve a requirements practice, the output should lead to a set of complete and quality requirements. A way to get there is to ensure that requirements have been captured in all pertinent categories and are testable. Often times, requirements focus on user needs and limited functional areas. But what may be overlooked are lesser requirements categories (e.g., security, usability, etc). It is therefore essential to capture requirements that ensure coverage in the requirements space.
Vague or missing requirements are a frequent source of delay when planning and managing testing and result in system defects and omissions, difficulties estimating test effort, and precious time spent getting clarity. In this article, Clare Roberts shares insights from recent projects, including checklists for spotting gaps in requirements and suggestions for prevention.
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.