Use Case Points are used as an analysis phase technique for estimating software development. Assuming the Business Analyst (BA) composes system use cases for describing functional requirements, the BA can use this technique for estimating the follow-on implementation effort. This article reviews the process of estimating the follow-on development effort for use cases.

It seems every now and then someone comes along with a new spin on how to estimate a project, either in its entirety or a portion of it. I have heard a lot of theories over the years, particularly in the Information Technology (I.T.) field where there is a tendency to pull numbers out of a hat, but I've long given up looking for panaceas.

Software development process is undergoing seismic shift from traditional waterfall software methodologies towards agile methodologies. Agile software development methodologies deliver high quality software products in rapid iterations with high flexibility and adaptability to changing conditions. This article discusses the dynamics of agile projects by comparing it with the SDLC project framework to help the IT leaders and organizations plan effectively for transitioning to Agile software development methodologies.

Congratulations! You've just won your first large client and you are being chosen to play the role of the Lead Implementation Consultant for the engagement. You are being chosen because you are, at your core, an excellent BA and have a very high level of expertise about the product or solution that has just been sold.

As agile methods become widespread in organizations, it’s not surprising to see the idea of the business analyst as a dispensable role taking root among IT project teams. After all, in agile approaches, tasks typically performed by a business analyst, such as requirements elicitation, analysis and documentation, are replaced by a conversation between customer and developers.

There are considerable benefits from extending business process management capabilities outside the boundaries of the company, and clearly measurable value is much easier to quantify when stakeholders are outside the traditional walls of the business.

Over the years I have noticed that we, as Americans, seem to possess a knack for attacking the wrong problems which I refer to as the “Rearranging the deck chairs on the Titanic” phenomenon. I see this not only in the corporate world, but in our private lives as well. Instead of addressing the correct problems, we tend to attack symptoms.

At UC Berkeley there has been an increasing awareness of the importance of business analysis (BA) and user experience (UX) in the software development lifecycle. In this article we will discuss the advantages of involving BA and UX practitioners in your development process, when and how to involve them, and the similarities and differences between the two professions.

Recently, I was watching an episode of "60 Minutes" which discussed the prosecution of a whistle blower at the NSA regarding the development of a major system to be used in the War on Terror, code named "Trailblazer." Although the intentions of the developers may have been good, the project started to spiral out of control almost from the beginning.

A swimlane diagram is a type of process flow diagram (also sometimes called a cross-functional diagram) that features divisions or "lanes." Each lane is assigned an actor (which may be an individual, department, division, group, machine, entity, and so on), or even a phase or stage in a process, that is responsible for the activity or work described in the lane.

I recently saw the "The King's Speech," a movie about the relationship between the stammering King George VI of England and his speech therapist... how is this commoner able to help the monarch and become his life-long friend? He is a master at influencing with absolutely no authority.  There are some lessons here for those of us business analysts and project managers whose jobs depend on our ability to influence without authority.

Structured business vocabulary is a missing ingredient in most current approaches to developing requirements. This omission should greatly concern every business analyst. Indeed, business vocabulary is key to a whole range of fundamental challenges, including but not limited to capturing business rules. One reason is that business vocabulary, like data and business rules, lives on beyond the point of system implementation and deployment.

How come product owners and teams struggle to use the product backlog effectively? One of the reasons lies in the linear nature of a traditional product backlog: It is a list of "features, functions, technologies, enhancements, and bug fixes," as "Agile Software Development with Scrum" states. Such a list works well for creating a simple product. But it can be inappropriate for a more ambitious one.

More and more organizations are taking advantage of business process management (BPM) solutions. And yet, it is often the case that, after an initial success or two, the growth of BPM within a company stalls.

We BA's are occasionally asked, "What do you do?" I try to make a joke out of this innocent question by replying, "Well, what would YOU do with English and writing degrees? I'm a Business Analyst of course." People don’t laugh.