Posted by Robert Merrill on September 15, 2009 under Agile BA, Agile Methods, Business Analysis and Requirements | 
I gave a presentation on “The Role of the BA in an Agile Environment” at the meeting of the Madison chapter of the IIBA (International Institute of Business Analysis) on Tuesday 9/15/2009. Because I delivered the presentation like an Agile project, with the audience developing a “product backlog” of topics for me to present in priority order, I had deliberately prepared more material than I had time for.
For you Madison IIBAers who’ve come here looking for the material, I haven’t posted my PowerPoint slides (and don’t plan to) because they aren’t able to stand on their own. As I get the chance, I’ll turn some of them into blog posts. Please let me know what would be most valuable to you and I’ll work on that first, according to the “maximize value within constraints” principle.
And thank you for being such a high-energy audience. I had a blast, but was totally wiped out when I left for home. I know that the Agile methods are rocking your world, and I want to help you, to quote Kent Beck, “Embrace Change,” if I can.
Posted by Robert Merrill on July 2, 2009 under Business Analysis and Requirements |
From Use Cases to User Stories, I’ve always struggled with how to treat the non-functional requirements. I haven’t tried it yet, but this article by Ryan Shriver on Qualities and User Stories contains something that looks like it just might work:
Name: A unique name for the quality
Scale: “What” you’ll measure (aka the units of measure, such as seconds)
Meter: “How” you’ll measure (aka the device you’ll use to obtain measurements)
Target: The level of performance you’re aiming to achieve (how good it can be)
Constraint: The level of performance you’re trying to avoid (how bad it can be)
Benchmark: Your current level of performance. Read more of this article »
Posted by Robert Merrill on December 1, 2008 under Business Analysis and Requirements |
Modern software development processes are moving away from legal-document-style “the system shall” requirements to less formal User Stories. Further, software users and buyers are encouraged to write user stories themselves. If they’re used to being interviewed by a business analyst and then being handed requirements to review, this can rattle them at first.
I often have to show them what I mean by User Stories, and I use a template I think I got from Mike Cohn’s User Stories Applied (It’s a great book, even if it’s not where I got the template):
As a ______, I can ________ so that ________.
For example,
As a telemarketer, I can see the customer’s last three orders, including returns, so that I don’t offer them what they already have, or worse yet, what they bought and sent back.
But I’ve also done enough requirements workshop facilitation to know that when you ask a different way, you get a different (and often valuable) perspective that would have otherwise gone missed. Not the end of the world on a well-run agile project, but it’s still beneficial to get as many of the stories as you can to start with.
To really get subject-matter experts thinking business and not systems, I’m starting to use this variant:
As a ________, when ________, I can ___________ so that ____________.
If you first have the group create a list of business events, you can use those to drive another round of story writing. Suppose we identify an event “my shift ends.” That might remind people of another story:
As a telemarketer, when my shift ends, I can review my call statistics and add notes for my supervisor, so s/he knows about any extenuating circumstances I encountered, and I still get the credit I should.
The next time you’re helping people get started with user stories, try the event-driven variant. You and they may both like it. And check out this other template for non-functional requirements.