Resources for Business Analysts

If you have visited my site at www.ResourcesForBusinessAnalysts.com I’d really like your feedback.

What is the value of the site for you?

Is it the kind of information?
The quality of information?
Is it easy to find the information?
Does it save you time?
Is the information useful to you?
Does it help you look good – more professional – in your job?

What do you find valuable in the site?

Could you post to my Facebook fan page and let me know? Resources for Business Analysts Fan Page I left a “bribe” for you on the fan page as a thank you for your participation. This is a paper I have never before published on creating acceptance criteria for iterations/sprints/etc. This should be useful to anyone on any kind of Agile project.

Thanks much!

Geri

Author: Geri Schneider Winters

Meeting facilitation involves a number of skills, because your job is to guide the participants in addressing the topic of the meeting. If they need to make decisions, you guide them to make the decisions. If they need to brainstorm, you guide them in brainstorming exercises.

1. You have to be a really good listener and pay close attention to everyone.
2. You have to keep the goal of the meeting firmly in mind so you can make decisions such as: This topic needs to be addressed in a separate meeting, so stop the discussion and move on. OR This topic has been decided, so record the decision and move on. OR Some people have not given their input and I need to draw them out on this topic.
3. You need to be firm in managing the people – make sure one person is not doing all the talking. Make sure all people get a chance to express themselves (as appropriate).
4. You need to be disciplined to not get involved in the discussion and to make sure you have someone else working as scribe and taking notes.
5. You need to take care of details such as making sure a room or conference line is scheduled, creating and sending an agenda, sending invitations, making sure the important people can attend, and making sure everyone understands why he or she is at this meeting.
6. It helps a lot to be a calm, even tempered person, and to have confidence in yourself.

I don’t know the company, but I found online a place that offers training in meeting facilitation: http://www.facilitator4hire.com/ Their training prepares you for IAF (International association of facilitators) certification: http://www.iaf-world.org/i4a/pages/index.cfm?pageid=3672. This looks like very useful training to me, since being a good facilitator is a useful in so many situations.

=====================================
Now it is your turn.

Have you trained to be a meeting facilitator? Where were you trained?
Have you worked with a trained meeting facilitator? Do you think the meeting worked better with a trained facilitator leading it?
=====================================
You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.ResourcesForBusinessAnalysts.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

Author: Geri Schneider Winters

An interesting question came up in another forum, and I would like to address it here because I think it is a common one.

I am currently struggling introducing use cases into a large product development organization and a prime obstacle I am facing is that one use case should be all sort of things to different people. For Product Managers it should be dead simple focusing on high-level application functionality and scenarios (probably close to user stories), for the Developer it should be much more detailed and written with great rigor (scenarios described with activity diagrams); not to mention the Usability team who see use cases as Alan Cooper in About Face. I am wondering how to address all this. In architecture we came up with the View Points. I am wondering which way is better: (a) providing different perspectives on one use case by filtering some portion of its description, or (b) deriving more detailed use cases from one higher-level use case. Although it may lead to duplication, I intuitively bend towards solution (b). It provides better separation of concern. Any thoughts on this?

I think use cases are a wonderful tool. I have been using them, writing about them, teaching them to other people since sometime in 1996. But they are only one tool in my toolbox.

I think of it this way – a use case is not a kind of information, it is a form of information, a template, a way of structuring information. If you are describing a process, a procedure, a sequence of steps, then a use case works very well. But other forms may be better at describing your information. A use case is a poor choice for sequences with a lot of decision points (for example). In that case, I would look at activity diagrams, flow charts, or state machines to describe the information.

When choosing the form I will put my information/requirements into, I think about the information itself (as I just described), but also the people who will consume the information and what form will make it easier for them to consume it. When I was working on an embedded system with a bunch of electrical engineers, I used a lot more state charts, which I do not use at all with my IT business stakeholders. There is nothing wrong with producing the same information in different forms – user stories for the project sponsor, state machines for the engineers, for example.

While use cases started out as a way to describe telephone switching networks (see Jacobson’s early work in the 70’s for example), they have become a tool for describing user driven behavior. I have used them for embedded systems, but in that case, you really need to be careful about what is driving the system. It is very likely not a person, so the use case should be focusing on the actor/thing that is driving the process/behavior of the system. That may be hardware or another system, or even a clock.

So the answer to the question is, figure out the best form of information for each audience and create the appropriate documentation/diagrams/whatever. Just like the different Architectural Views Ponits, we have different views of requirements for different audiences, and those different views will probably not all be use cases.

=====================================
Now it is your turn.

What kinds of forms have you used for presenting requirements to different audiences? Do you write use cases for everything? Do you maintain different versions of the use cases for different audiences? Or do you maintain your requirements in different forms – user stories, use cases, sequence diagrams, state diagrams, flow charts – for different purposes?
=====================================
You are invited to re-publish articles from this blog, in your publication or website, as long as the article is intact and you include the following Byline paragraph (with live links) after each article you use…

START BYLINE

* Article used with permission from Wyyzzk, Inc.’s Resources for Business Analysts site at http://www.ResourcesForBusinessAnalysts.com This website of reports and tips contains information to help you succeed as a Business Analyst in IT.

END BYLINE

I just created a Facebook Fan Page for Business Analysts. Click on the badge below to see the page. Become a fan and let’s have a conversation there!

Resources For Business Analysts – Tools for Career Success

Promote Your Page Too

If you could ask me any question at all about improving your productivity and performance as a Business Analyst, what would that question be?

Every month on the second Thursday, for one hour in a teleseminar/webcast I will answer the questions you have posted at this site: Ask Geri a Question. This one hour session will be live at noon Eastern time. The recording and transcripts will be posted afterward on the Resources for Business Analysts site.

When you ask a question, I’ll put your email address on a list that I am only using to send monthly reminder notices of the Ask Geri sessions. This is a completely separate list from any other mailing I do. Every email has a link at the bottom where you can unsubscribe if you are no longer interested in the Ask Geri monthly calls.

The next session is coming up in a few days, on Thursday January 14th at noon and 7pm Eastern time. Be sure to enter your question here Ask Geri a Question and I’ll send you full details of the call.

I look forward to your questions!

Geri