Test planning is often thought unnecessary in an agile project. However, if our mindset is on "planning" rather than "plans," we see that test-planning activities happen throughout the project, taking advantage of levels of precision, i.e., what is absolutely necessary at each level.
We all want to satisfy our users, but tailoring software to customers is easier said than done. Personas—a method to synthesize your primary users into abstract entities—facilitates understanding of goals and experiences.
Agile teams need to analyze product requirements in enough detail to build, test, and deliver the right requirements in short time frames. For the many teams that struggle to define "just enough, just in time” requirements, here's help.
What is your project's analysis debt load? What's the difference between good and bad analysis debt? What are causes and remedies for such debt? Mary Gorman and Ellen Gottesdiener explore the concept of analysis debt and consider strategies for prudent investing.
Whether you're working on a collocated or a distributed team, it's important to take stakeholder requirements into account: "Who" are they and "where" are they located? In this article, Mary Gorman offers some tips to help you narrow the gap between thinking and acting globally and locally.
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 the top five requirements risks.
It's easy to get caught up in the inertia of a project and forget to ask exactly what we are developing, who our customers are, and what their goals with our software might be. Few software projects have the time and budget to figure out what their project is through trial and error. Getting clarity on project focus not only helps productivity, working to create software that people actually need increases our chances for success.
In these times, many of us are being told to "do more with less." A more useful approach is "invest our organization's scarce resources where the return is the greatest." To do so, we must define the financial benefits sought when developing a system in addition to its requirements.