An example of Blueprint in Use on an Agile Project

I attended a talk by folks from BluePrint and Lexis Nexis at BAWorld on Tuesday at BAWorld: Boston called "Requirements Definition for Agile Projects". The first bit of the talk was just an intro to agile and why it is useful on the projects. The part that I found most interesting was from Kathleen McGoey who owned business analysis on lawyers.com - she effectively gave a verbal case study of their team using agile and Blueprint to deploy this site. This was refreshing because she was brutally honest about the state of their organization 2 years ago, some of her dislikes about other tools, and their experiences with agile not going well. However, she also then talked about how their culture is changing now and what is working really well. This talk was great because it was effectively a great sales-pitch for Blueprint, but it was given by an actual user....and you could tell she was being honest about it.

Blueprint is meant to be a BA tool. They are closely partnered with HP and it integrates to Quality Center for QA use as well. From a quick glance of things she mentioned or showed, it looks like it allows you to manage the list of features in a backlog, low-fidelity wireframes, diagrams that look a lot like visio, export to Word, and import from Excel. We are still using Borland's Caliber happily, but I'm obviously always looking at all the tools on the market to see what people are really liking and/or disliking, what new features are coming about, what's easy to use, etc.

A bit about the lawyers.com project - they were executing 3-12 week sprints and the requirements definition is about 2 weeks ahead of sprint cycles. She made a very wise comment - templates and processes are good to an end, but only if the BA knows what they are doing already. She spoke of junior analysts who are given templates and when you look at their work products you think “Oh no! what are you doing!”. I think we’ve all probably seen that. You can use the templates and processes to train them, but they aren’t enough, but they aren’t enough.

Another neat thing she briefly mentioned was the idea of doing something like pair-programming, but where the pair consists of a BA and a user experience expert – so together they are designing the wireframes. I haven’t tried it, typically our individuals are doing both activities.

Anyway, it was good to hear the “how it works” story from Lexis Nexis. And I haven't used Blueprint myself, but I am certainly interested to hear others' experiences with the tool, so please comment if you have used it.

Creating BA Competency

As part of our Live from BAWorld: Boston series, I just heard a talk from Karen McKay at Doreen Evans Associates (DEA). She discussed building a BA competency in your organization. Her talk was focused on the high-level need for such a model and what the components of it are. I think a next level of discussion that would be interesting is tactics you could use to create one yourself - which specific tools and tactics work.

At DEA, they use a model that is very similar to the CMM, with five levels of competency: initial, repeatable, defined, managed, optimized and have helped build this at a handful of organizations. We do something similar to build BA maturity in organizations, but I haven't actually seen it laid out next to the CMM model quite like this. At the requirements process level, they use requirements models which I applaud - context diagrams, org charts, use cases, process flows, DFDs, etc. This talk further validated what I'm seeing in industry - alas, models are really the current state now. So if you write your requirements in plain old text, I fear that is really seen as out-of-date "technology" and you need to look at visualization techniques.

Something interesting that she did with her slides was to describe parts of their competency models using requirements models. For example, there is a swimlane diagram to show the BA role - clearly showing how BA activities relate to IT and PM functions. I haven't done much of this recently and think it's a great idea that I will use.

Anyway, this is a topic that I'm definitely interested in as we try to help customers build their competency around requirements as well. It seems like organizations are really recognizing the value of BAs now!

Using Use Cases To Create Test Cases

As part of my "Live from BAWorld: Boston" series, I attended a talk Monday by Matthew Leach of Doreen Evan Associates called "Leveraging Multi-Level Use Cases for Testing and Other Ways to Obtain Greater ROI on your Business Analysis Investment".

His talk went into great depth about how you could use use cases on your project in multiple ways, looking at different levels of detail in use cases. He quoted a study from VokeStream that indicated 76% of people surveyed manually build test cases still.

This is the one point I also wanted to emphasize the importance of: re-use your use cases to generate test cases, particularly user acceptance test scripts (UAT scripts). At some level this seems obvious to me, but I don't think it is all that obvious after all based on the above study, Matthew's experiences, and my personal ones as well! On a recent project I worked on, the business came to us to talk about how awful the integration and unit test cases were - that they just would not work for UAT. My immediate thought was "well of course not, those aren't meant for UAT". Apparently QA had told them to write their UAT scripts from these test cases. That's almost as challenging as writing them from code! So we walked them through how we could take the use cases we had written (which the existing test cases were generated from) and easily translate those into UAT scripts.

If you think of your use case having a happy path and alternative paths, you would want to blow out each of those paths into at least 1 test case each, by adding concrete data to the use case. So for example, if there is a step for the user to input "shipping information", then in the UAT script, you would want to supply actual shipping information including a specific name and address that would be in the test data set. It's important during UAT to also test the alternate and exception paths - to ensure the not-so-happy path and errors are handled to the business' satisfaction. That said, it's also unrealistic to think your users have time to test all possible paths. To mitigate this, I have two suggestions.

1. Pick the most important UAT scripts to test. You have to decide what "important" is, but it would be wise to look at the use cases that add the most business value and/or are most frequently used.
2. Use your BAs during UAT - particularly for the less important test cases that the users can't it.

Live from BAWorld Boston

This week I find myself at Project Summit & BAWorld: Boston for about a day and a half.

This morning I presented our talk, "If you Build It, Will They Use It? Leveraging Business Objectives to Deliver Successful Projects". One thing I like about the BAWorld symposiums is that they make the slides available electronically to everyone, they are reviewed by a committee before you can present them, and they insist that the speakers provide learning objectives so you know what you are getting. So to that point, here are the learning objectives for my discussion:

• Understand how Business Objectives are vital to businesses
• Understand how to elicit and write good Business Objectives
• Understand how to use Business Objectives to assess measurable value of individual features

I had a blast with the audience here - great participation in some of my games (yes, we do them in presentations, not just our training classes!).

If you haven't been to one of these conferences, I recommend it if you are a practitioner doing Business Analysis, Requirements Engineering, or Product Management. Everyone else here is also practicing the "art" of BA and looking for new tips and techniques to take back to their organizations.

Anyway, I attended a few other talks of interest today that I'll blog about shortly!

Live from BAWorld: What To Do With Interfaces

Mary Gorman from EBG Consulting presented “Integrating Interface Analysis into your project: Just-enough, Just-in-time”. This talk was one of the advanced topics, with the intent of teaching about how to do interfaces – software, hardware, and user interfaces. I’m going to capture some summary points from her talk, either the key points or the ones I found most important:

1. She talked about just-in-time interfaces, specifically of interest is that idea that you can identify interfaces early in the project (first days even). A lot of projects wait on these, but there is no reason for that and you may miss things if you wait.
2. Do just enough. In some cases you can do minimal formal documentation, just enough to build and demonstrate the system, whereas other times you need very formal structured documents.
3. Business rules are at the center of all models. They are used by all models, and you will discover them in most models.

Mary talked about interfaces in various types of projects. For example in COTS projects, interface work is usually not about the user interfaces, but rather more about system-to-system interfaces since the COTS software has to integrate. When working on a project to update a system, existing interfaces have to be looked at for updates, and new interfaces or users might be added.


And she points out that a nice bonus from working on interfaces is that you also will likely improve your user requirements – by finding new users, new stories, incomplete stories (missing interactions), missing data attributes, and missing business rules.


My favorite part of this talk is that Mary used a role playing exercise in which people played different systems or the customer, and they used a ball that was tossed around to represent data passing between systems. She used it today to demonstrate the concept, but I talked with her afterwards and she does in fact use this technique for eliciting interface requirements.

I was excited to attend this talk because I have a lot of respect for Ellen and Mary from EBG, they seem to know a lot about practical things about requirements (as compared to a lot of the speakers who talk so high-level it's not usable material). They have some good books and whitepapers to learn from outside this forum if you haven't read them.

Live from BAWorld: A BA Mentoring Program

I heard a talk on building a mentor program for business analysts (BAs) by Dave Ramauskas from HTSC, along with 2 people from his mentoring program. They started by describing a challenge which we’re familiar with – that it is hard to recruit really good Bas, and very few of those found are hired. That’s why it’s important to use mentoring to grow the junior BAs and retain the senior ones.

They did a nice role playing skit to demonstrate what the mentoring relationship might look like in a specific scenario. As a side note - there were only a few talks I’ve seen here that did something like this, and they are all my favorite talks.

They walked us through the details of their mentoring program. And like with most companies, it’s a challenge to get a program up and running certainly, but they seem to have done well for a first cut. Here are the things they did, with my comparisons to how we handle this at Seilevel.

1. How to match mentors and mentees: Some suggested using personality profiles, others suggest just matching based on skills. They tried a variation on “speed dating”, they call it “speed matching”. In our organization, we let them pick each other. The mentors decide to be mentors, publish a little piece about their mentoring style, and mentees get to leisurely browse the profiles and talk to the people until they find someone they want as a mentor. The two parties then decide if there is a fit.
2. Implementing the program: They suggest using a written development plan for the mentee to help focus the mentoring efforts. They referenced a Harvard study to demonstrate the value in writing goals. We use something similar where we have mentees work from an organized list of skills areas for the growth path we want people to go through.
3. Wrap-up: They do a graduation from their mentoring program. This is different than our mentoring program, which is always ongoing. I believe their structure to it suit their need of growing a set of highly talented newer resources for a period of 9 months each year.

Mentoring requires time and resource commitment from both parties and management to put time in it, and for the most part they seemed to have that. Also, it’s worth mentioning that some of the specific BA skills are not trivial to mentor. They didn’t really address this aspect at all, but from my own perspective that the average person isn’t necessarily going to be good at mentoring something like elicitation or facilitation skills. In the end, I think they do some things very well. I cannot stress enough that our mentoring program is a work in progress to say the least, so I'm thrilled to hear about some others trying to set this up as well.

They suggested a couple of books on mentoring:

1. Strength finder 2.0 - Apparently there is an online tool to help you identify your strengths, and the book helps figure out how to apply those at work.
2. Mentor and Mentee Guides

Live from BAWorld: A Case For Visual Models

I heard a presentation at BAWorld, but for this one I won't mention who it was, because I'm going to critique it in a very specific way. The talk wasn't bad per se, but one thing about it really bothered me. You see, the speaker displayed a slide that was supposed to convey traits of an effective team. The slide contained a circle with 16 lines coming out from it (like a sunshine almost). Each line had a trait on it, for example "committed", "conflict management", "self directed", etc.


The speaker then asked us "What traits are missing?" And my immediate reaction was to go to a place of "Seriously? You want me to read a list of 16 things and tell you something meaningful that is missing?"


So this is another fine example of Miller's Magic number, aka 7 +/2, where the human brain can only hold that many things. So by the time I get to item 10 out of 16, it's unlikely I remember the first.


Add to that, the ideas around the wheel aren't parallel ideas, so it's even more frustrating. If you are going to make a list like this, make them the same type of word - i.e. verb, noun, etc. Ideally they should be of similar type too, but that's harder to measure.


And finally, if you are going to use a visual to display your list, that's great, except that it needs to be one that actually organizes the information in a way that is useful. A circle of lines did not help organize the list. Maybe if he had grouped items together, there would have been 7+/2 items at the first level, with a few branches off each of those.


People did play along and shout ideas, but honestly, I thought the ideas overlapped with what he already had up there. Who knows.


This whole example is simply more justification for why we use visual models to represent information. With an appropriate model choice, we wouldn't have to remember 16 things, it might have helped force a parallelism, and finally it will help organize the information.

Live from BAWorld: Getting Your Stakeholders to Help You

Marie Bankuti from Tether Free Vision presented “Help Me Help You! How to Proactively Educate Your Business Stakeholders for Greater Project Success” this morning at BAWorld Boston. She discussed the typical challenges to project success that we see on projects and had the audience contribute. The ideas the audience came up with included conflicting interests, trouble articulating a vision of success, business users were cocky and thought they could do it without IT’s overhead, no time from the business, and pressure to hit dates and cannot focus on what is really needed in that time.

To summarize Marie’s suggestions:

1. Understand your stake, meaning vision or mission. Understand yours, your users’, your IT groups’, your and company’s.
2. Nurture your relationships, including understanding the people who you work with, their pains, and even what they do outside work.
3. Explain your process. Do this through things like case studies of it working or not, and just explaining why it’s needed.
4. Define expectations. Make sure it’s clear how you each will communicate, what the roles and responsibilities are, and what accountability there is.
5. Ensure credibility. This means things like disagreeing tactfully and with respect, collaborate, follow through on commitments, but in general model the behavior you seek from the teams you work with.

All in all, Marie gave a nice general overview of how to get teams to work with you.

Live from BAWorld: A Funny Start to the Day

A couple of us from Seilevel are representing at Project Summit & BAWorld Boston this week. So in typical form, we’ll be blogging live from BAWorld as the inspiration hits us.

This morning’s keynote talk was by Simon Cotter and it was on “The Power of Humor in the Workplace”. He’s a real estate/sales guy turned standup comedian. Now, I have to admit, it was a bit early in the morning for me to be laughing out loud, but I did find him amusing. It was a creative keynote. Frankly, I tend to find keynotes typically too broad to be applicable or by people who have big names but aren’t necessarily great at presenting. This guy actually kept me engaged for an hour and certainly handled the crowd well. His general point was about how to use humor to develop relationships. If you do that, people simply will want to work with you. And then he had more practical tips about how to do this if you don’t think you are funny - things like using safe jokes, quick wit, self-deprecation, and physical objects.

I completely believe in this concept. You know, I look forward to the funny people coming into the office every day. Who doesn’t love a good laugh? And you don’t have to be an overall comedian, just amusing sharing anecdotes with the crowd can make your coworkers chuckle and bond a little. In our training, we try to add some bits of humor to keep the students awake.

Anyway, there are 2 points I think are important in using humor – keep it appropriate (sexist and racist jokes are off limits) and keep it in check (we are here to get a job done, not just to be funny). Can you think of times where people were relying so heavily on their humor that they keep you from actually getting to the point? You just want to make sure everyone is engaged with your humor and move on to complete the task at hand.

Ok, so I feel like I should end this with a joke. Here goes:
A Business Analyst and a Project Manager walked into a bar....
Ok wait, unfortunately, I got nothing! Feel free to add some funny comments though.