|
Why Not Ask Why? Get Help From the Satir Interaction Model Having trouble with responses to why questions? Get help from the Satir Interaction Model and learn when to use data-oriented questions.
|
|
|
Harvesting Stakeholder Perspectives to Organize Your Backlog 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.
|
|
|
Building Team Trust, Front to Back Trust is more than a feeling. In a project, it is something that can be grown from careful planning and development of good requirements. Ellen Gottesdiener describes three types of trust which can be built from good requirements and team management.
|
|
|
Acceptance Test-Driven Development: Not as Optional as You Think The components of software processes work together in important and sometimes unrecognized ways. The removal of one of those components will affect the others. In this article, which originally appeared in the August 2010 issue of the Iterations eNewsletter, Jennitta Andrea takes a look at the value of acceptance test-driven development and the costs of making it an optional practice.
|
|
|
9 Questions You Must Ask When Selecting the Right Tool and Vendor The key to selecting the best vendor and tool is asking the right questions. The answers to these nine essential questions can mean the difference between satisfaction with your purchase and a giant waste of time and money.
|
|
|
How Agile Practices Reduce Requirements Risks 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.
|
|
|
A Second Look at "Requirements Come Second" My article, "Requirements Come Second," in a recent issue of Agile Journal caused something of a fuss. The piece was picked up by several more sites and was widely commented on - both on websites and in my inbox. I'm not entirely surprised by this reaction, I've been discussing this research for a year or so now and often find it surprises people. Given this level of interest it is worth looking at how people responded. It is also worth restating the key message: Requirements are an essential part of maximizing business value, but when an organization is struggling with effectiveness it is best to start change by improving delivery.
|
|
|
An Agile Approach to Scheduling When we schedule too many variables, things start to slip and soon the schedule is out the window. Paying attention to your project's constraints can help you set realistic scheduling goals that you will actually be able to stick to.
|
|
|
Transitioning from Analysis to Design The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.
|
|
|
Agile Testing as if People Mattered As a test professional in waterfall, I was used to getting the code much later and buggier than I expected and being under tremendous pressure to finish my testing before the go-live date hit. Then one day, I found out that there was a better way. Testers could be involved much earlier in the lifecycle, they could participate in requirements and design decisions as they happened, and the code could actually be unit tested before I received it! Heaven? Nope, agile.
|
|