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.

Kipling knew a thing or two about the written language. Tucked away in one of the Just So Stories were a group of words which have become the basis for information gathering, criminal investigation, scientific research and news reporting around the world – Who, What, Where, When, Why. These have become known as the 5 Ws.

The 5 Ws can also give user stories a greater depth of meaning by expanding on the business functionality required by the user.

“As a who when where, I want what because why.”

Here’s an example:

As a call centre operator (Who)

answering customer calls (When)

in the call centre (Where)

I want to be able to verify the customer’s verbal passcode (What)

so that I can authenticate them (Why)

Now you might consider that some of the information in the above example is obvious and needn’t be stated – of course an operator will be in the call centre when they’re answering calls. But what if the operator is in another office in the building and logs in? Do you still want them to be able to access potentially confidential information outside the secure environment of the call centre? Suddenly this 5 Ws user story can also be a trigger to review access and viewing permissions when separate information threads are combined on one screen.

For specifying complex functional requirements, user stories won’t be replacing use cases any time soon but the 5 Ws approach will result in a more specific statement of business need. This in turn will help developers understand more about the context of the functionality that needs to be provided.

P.S. If you have the time to read Kipling’s poem (The Elephant’s Child) you’ll notice that it’s actually 5 Ws and a How. But we all know that business analysis is about the what rather than the how… don’t we?

If you enjoyed this article, you may also enjoy these:

What Happens After User Stories?

How Clear is your Writing?

Use Case Fragments

The post User Stories & The Jungle Book appeared first on IRM Training.

How much documentation to produce is one of the most troublesome issues facing analysts today. There are no hard and fast rules on this and successful projects define their own rules to fit the circumstances and organisation.

However one thing every project has in common – there is always some documentation even if it’s only a terms of reference. Not many projects get signed off based on a verbal business case – at least the company accountant hopes not! Here are some guidelines to consider when producing your next set of documentation.

Read the full paper here: Just Enough Documentation

If you enjoyed this paper, you may also like these:

How to Deliver a Recommendation

Writing Better Requirements

Stakeholder Communications – Pictures not Words

The post Just Enough Documentation appeared first on IRM Training.