Intentionally Incomplete
This is my initial blog for BA Times and I’m certainly happy to be joining the community. So, a little about me-
My name is Bob Galen and I’m from Cary, North Carolina. I’ve spent the greater part of 25 years in software development-in roles such as developer, manager, director, project manager, tester, and project manager.
For the past 10 years, I’ve been moving my thinking and practices towards those espoused to the Agile Methodologies. I’ve found them to be the most congruent, humane, and effective approaches for delivering software and I try to share my insights with everyone I meet.
Perspectives – you’ll see a strong skew in my blog posts related to the following topic areas:
- Implications of software testing for the BA
- Implications of agility for the BA
- And leadership and soft skills topics for the BA
So that gives you a feeling for coming attractions. But, enough of that…
A key requirement artifact in the agile community is the User Story. Mike Cohn does a nice job of covering them in his User Stories Explained book. I may go into more definition later on the topic, but I wanted to explore one critical characteristic of the user story now. That characteristic is this –
The user story is intentionally incomplete. Yes, you heard me right. It’s ambiguous. It’s got glaring holes. It fosters questions…lots of them. Those questions come from different perspectives too. The developers will have a different set than the testers. Or the BA. Or the architects. Or even the ‘customer’.
What’s the point of having a requirement that is ill-defined? I’ll tell you. It’s to drive conversation surrounding each requirement from the host of different perspectives needed for their implementation. You see the questions are expected…in fact, demanded in agile teams. There’s the agile manifesto notion of “People and Collaboration over Process and Tools” and the user story is an initiator of this collaboration.
I think of it not as two-way collaboration, but multi-way collaboration. Minimally, when a team member picks up the user story for implementation, they gather in a triad of three primary roles-the development-centric, testing-centric, and business/customer-centric views. They discuss the details of the story from each of their perspectives and refine it.
Not only refine it, but leverage all of the knowledge gleaned so far from previous story development and project execution. That’s a key here. You defer specific definition realizing you’ll gain richer information with each Sprint or Iteration that you execute. So this “working software” knowledge is also spun into the evolution of each user story. Another driver for this is Lean’s Just-in-Time and Just Enough thinking when it comes to software development. It turns out that we’re often quite presumptuous in our software development efforts. We assume that we can predict the future in requirements or design of software or even our planning without first writing some of the software.
That approach perhaps works for simple or by-rote things, but not for complex applications or those that are new, novel, and competitive solutions to our customers’ problems.
For those of you struggling with this conversation-based requirement approach, I’ll leave you with a final thought. Have you ever seen a written requirement drive development and testing work that, when you pulled the two together, the code didn’t match the tests? Of course you have. I’ve seen this occur way too often. So while writing requirements is good and necessary, the user story is perhaps touching on an important but missing element in our requirement elaboration.
To be continued…
Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected]