While user stories do a great job of expressing functional (and often non-functional) requirements in words that business users can understand, that’s not the case for developers. Remember that a business analyst is the communicator between the business AND the developer. There just isn’t enough information in a user story for a developer to do their job.

So how do you get round this? For a really interesting discussion on this topic have a look at the following article Why I still use Use Cases by Alistair Cockburn. Alistair was one of the original signatories of the Agile Manifesto and his article includes observations on some of the key issues faced by organisations using agile methods.

WHY I STILL USE USE CASES

XP pretty much banned use cases, replacing them with the similar sounding “user stories” and as a result agile zealots have been happy to dump use cases in the trash (along with their project managers, estimates, plans, and architectures). Scrum did similar, using the “product backlog” instead of user stories. Yet as I go around projects, I keep running across organizations suffering from three particular, real, painful, and expensive problems:

1)   User stories and backlog items don’t give the designers a context to work from – when is the user doing this, and what is the context of their operation, what is their larger goal at this moment?

2)   User stories and backlog items don’t give the project team any sense of “completeness” – what I keep finding is that the development team bids/estimates the projects at (e.g.) 270 story points, and then as soon as they start working, that number keeps increasing, seemingly without bound. The developers are depressed and the sponsors are equally depressed by this. How big is this project, really?

3)   Related to completeness, user stories and backlog items don’t provide a good-enough mechanism for looking ahead at the difficulty of upcoming work (In principle they could, just in practice they don’t) – I keep hearing this complaint, “We asked our customer (product owner) a question and she/he took 2 weeks to get us an answer. We must have the wrong person in this role.” No, they don’t have the wrong person, they have a broken process – certain types of questions take a long time to research, as the various departments and user groups work out what is the correct, balanced answer for the whole lot of them. Staring at the set of extension conditions in a use case lets the analysts suss out which ones will be easy and which will be difficult, and to stage their research accordingly. User stories and backlog items are not set out in that granularity early enough on for that assessment – the extension conditions are usually detected mid-sprint, when it is too late.

Use cases are, indeed, heavier and more difficult than either user stories or backlog items, but they bring value for that extra weight. As not-Einstein said: “Make things as simple as possible, but no simpler.” (The attribution to Einstein has been debunked, it seems.)

In particular, use cases fix those three problems.

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” … and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

In other words, naïve use of user stories and backlog items is causing very real, very expensive damage to companies. Expensive is bad.

The most recent was an executive who was telling about having “delivered” a Scrum project, but it was discovered at acceptance time that there were a whole series of recipients of the system whose needs hadn’t been identified at all. This company is now faced with writing what may amount to a fixed-price contract because the recipients aren’t sure they trust the company to deliver complete and useful software.

Very expensive, very bad. The time spent writing the use cases and doing a more thorough requirements investigation would have paid off handsomely, in this case.

Here 5 reasons why I still write use cases:

1)   The list of goal names provides executives with the shortest summary of what the system will contribute to the business and the users. It also provides a project planning skeleton, to be used to build initial priorities, estimates, team allocation and timing. It is the first part of the completeness question.

2)   The main success scenario of each use case provides everyone involved with an agreement as to what the system will basically do, also, sometimes more importantly, what it will not do. It provides the context for each specific line item requirement, a context that is very hard to get anywhere else.

3)   The extension conditions of each use case provide the requirements analysts a framework for investigating all the little, niggling things that somehow take up 80% of the development time and budget. It provides a look ahead mechanism, so the customer / product owner / business analyst can spot issues that are likely to take a long time to get answers for. These issues can and should then be put ahead of the schedule, so that the answers can be ready when the development team gets around to working on them. The use case extension conditions are the second part of the completeness question.

4)   The use case extension scenario fragments provide answers to the many detailed, often tricky business questions programmers ask: “What are we supposed to do in this case?” (which is normally answered by, “I don’t know, I’ve never thought about that case.”) In other words, it is a thinking / documentation framework that matches the if…then…else statement that helps the programmers think through issues. Except it is done at investigation time, not programming time.

5)   The full use case set shows that the investigators have thought through every user’s needs, every goal they have with respect to the system, and every business variant involved. It is the final part of the completeness question. (And yes, I did indeed sit down and walk through 240 use cases with a client, at the end of which, I turned to her and asked: “And is that everything?” She said, Yes, and we built that, delivered it, got paid for it, and it is still in use ten years later.)

The are several sticky parts for people using use cases as I describe:

*   It is really easy to think all the use cases have to be written up front, when in fact the writing should be staged over the life of the project. The “thinking’ part here is working out how much should be written up front to get the project estimate into a safe place, and which parts can be deferred to just-in-time investigation.

*   These days, iteration/sprint lengths are so short that it is not practical to implement an entire use case in just one of them. That means additional work is needed, to create user stories or backlog items for each use case, track that each one get developed, and ensure that the complete set of user stories or backlog items do indeed deliver the subset of the use cases needed for the particular release.

*   Writing good use cases (or any other requirements) requires thinking, communicating, and thinking again. It is much easier just to write user-story tags on index cards and let the project blow up later.

If you don’t want to think, find a new profession. Software development requires thinking, at all levels.

This article reproduced with kind permission of Alistair Cockburn. To read this and other articles by Alistair go to http://alistair.cockburn.us/Why+I+still+use+use+cases

If you enjoyed this article, you may be also interested in these:

How to Use Use Cases

How to Write Use Cases

The post What Happens After User Stories? appeared first on IRM Training.

With so many experienced business analyst looking for work, those employers who were hiring had the pick of a very experienced talent pool. Colin Penn, a business analyst with over 20 years experience, was one of the people looking for work and has given this personal analysis of how he saw the business analyst jobs market in the second half of 2009. It took Colin a few weeks of scouring the job ads to find his next contract but during those weeks he identified several profiles which came up repeatedly.

1. Technical BAs with facilitation skills. These analysts were required to have a working knowledge of IT architecture, applications and systems so that they could guide and advise participants during facilitated requirements gathering sessions. The ability to facilitate sessions was as important as a working knowledge of current technology.
2. Technical BAs with a development background and specific knowledge of .NET, JAVA, XML, SQL or similar. Whilst the jobs were advertised as a business analyst, the analyst would predominantly be working with specifications and dealing with development teams.
3. Business BAs with expertise in a specific industry. Many of these BAs were originally seconded to projects as the subject matter expert and from there made the transition into business analysis. Specialities in demand included banking, superannuation, utilities, supply chain logistics and telecommunications. Also in high demand was expertise in ecommerce, web based services (B2B and B2C) and specific software applications such as ERP (e.g. SAP, Oracle) and CRM (e.g. Siebel). Business BAs also operate at the strategic level although it’s rare these days. Current strategic thinking has evolved past the “aligning IT with the business” approach to now viewing IT as an integral part of the business strategy. More and more executives are becoming both IT savvy and business analysis aware, lessening the need for traditional, high-level business BAs.
4. Maintenance BAs are used by many organisations where there is an ongoing need to provide enhancements and changes to production systems. This includes both commercial and government organisations and is work carried out either by IT staff performing a BA role or business people who have been transferred into the role. There were not many positions advertised for these roles as the work can usually be performed by lower paid staff (higher paid contractors were the ones being laid off). Many graduates also start their careers as maintenance BAs and as the economy improves expect to see more business analyst jobs for this type of position.
5. The BA/Project manager was a common job description. Often advertised for medium sized projects, it can be OK in small dedicated teams, but the two roles can be contradictory on a larger project. The BA wants to find every important requirement whilst the project manager wants only the essentials in order to meet the deadline and the budget.

Previous project experience was also sought and popular areas included data warehousing, data migration, enterprise architecture integration and process automation. UML modelling skills were also in demand and to a lesser extent BPMN. There was also a distinction between data and process BA’s.

For a number of positions a testing background was also well regarded. This may emerge as a separate BA speciality with its own skills – testing tools experience and programming skills (such as SQL) for querying test results.

While not rigidly discrete, these classes of business analyst jobs show the diversity of the role and the fragmentation in the market. As in many professions, employers are becoming more demanding in the number and diversity of skills they want – especially in difficult economic times. Expect this to decrease as the economy improves and the pool of available talent shrinks.

A final word – all the job ads emphasised good communications skills. This has been, and continues to be the common factor for virtually every job that is advertised.

If you liked this article, you may also enjoy:

Hints and Tips for BA Job Seekers

The Creative Business Analyst

What is a Business Analyst?

The post Analysis of Business Analyst Job Adverts appeared first on IRM Training.