In principle, any physical model should have a corresponding logical model that represents a business’s own view of its needs in a technology-agnostic way. When it comes to data, that ideally consists of a business glossary and some sort of visual representation of the relationships between the business concepts defined in the glossary.
In my experience, most businesses don’t have a well-structured and up-to-date logical data model in place, if they have one at all. In fact, expertise in running a business does not equate to expertise in describing the taxonomy of the business and many subject matter experts are poorly trained in how to articulate their data needs.
What’s more, I have never worked on a Pega project where the physical data model was based on a logical one (before I explained the need for it, that is). I think that’s partly because Pega’s approach does not seem to pay any attention to logical data modelling (see my appraisal of Pega’s Direct Capture of Objectives approach). However, if you don’t have a meaningful taxonomy that describes clearly and unambiguously the nature of the concepts your business cares about, how can developers possibly build you a software solution that accurately represents those concepts?
When you are using a Pega Framework, such as Financial Services Industry Foundation 7.21, it comes with a ready-built class structure. However, as with any “off the shelf” solution, if you deploy it without checking to see whether it fits your needs, you are likely to run into problems. Adjusting process flows in a framework after the solution goes into production is relatively painless. However, adjusting the very structure of the underlying physical data architecture is costly once the solution goes into production and the longer you leave it, the more incorrectly-structured data it accumulates. Once a physical data architecture is in place, there is no “tweaking” it if it is wrong because it is the very foundation of the application. Fixing it involves significant refactoring and data migration. It is far more expensive than taking the time to get your data model right in the first place.
The ideal way to do a gap analysis between your business’s data needs and the capability provided by a particular technology solution is to compare your logical data model with the logical data model that underpins the technology solution. However, while Pega refers to its Financial Services Industry Foundation 7.21 entity relationship diagram as a “logical” model, Pega’s model is specific to its own technology and is therefore a physical model. Logical models are technology-agnostic.
I have created an A2 size entity relationship diagram (in Visio 2013 – download it here) that represents the kind of logical concepts that underpin the Pega FSIF 7.12 physical model. If you are a Pega Business Architect feel free to use it and adapt it to your needs. This version 0.1 focuses on the core concepts of Party, Account and Asset and in order to produce it I drew on my experience in modelling for financial services clients. You may have some questions regarding the cardinality of some of the relationships (e.g., why a particular relationship is “zero-to-many” instead of “one-to-many”). If so, feel free to contact me for an explanation.
I have attempted to normalise this model as much as possible but when you add all the attributes needed by your organisation, you may find it normalises further. You will notice that several entity types on this diagram correspond to a single data class in Pega. This is because physical data models are often de-normalised for performance reasons.
Several years ago a major software consultancy built a Pega solution for a client and within two years of deploying it, the client was having to rebuild it themselves. It’s not an uncommon scenario.
The client brought me in, because of my background as a Pega Business Architect, to take a look at the business architecture underlying the original solution and that is where I spotted the problems, which were almost entirely about the business’s inability to properly understand and articulate the nature of the things it cares about and the relationships between them. In other words, their inability to model their own data. This is a common issue which comes down to the following:
“The language of experience is not the language of classification” John Ciardi
The fact that a person is an expert in operating a business does not automatically make them expert in articulating the nature of that business or how it operates. In fact, their experience may even blind them to how that business should be operating.
Business subject matter experts (SMEs) often speak directly to software developers (or to requirements stenographers) using the language of experience, which is usually imprecise and inconsistent. However, computers operate using ones and zeroes. There is no room in binary code for: “You know what I mean” (which I have actually heard clients say during analysis workshops).
For example, on the project I mentioned above, I spotted that two intimately related, but quite different, business concepts were modelled as a single class in Pega. I challenged this and the main business SME’s response was that they modelled them the same because the business treats them the same. I needed to explain that the nature of a thing (data definition) and the way in which you treat it (process definition) were not the same and, moreover, defining things as different allows flexibility while still allowing them to be treated the same way.
I used the following analogy: Imagine you make fruit pies using both apples and pears. Two different, although similar, types of fruit, each with its own characteristics. However, they are treated the same way. They are washed the same way, peeled the same way, sliced the same way and put into the same pie. Because of this, you simply define them as “fruit”, with no distinction as to their taxonomy. Then one day there is a fungal epidemic which dramatically reduces the pear crop among your suppliers and the price of pears doubles. You need to know how this is going to impact the cost of producing your pies. However, you cannot say because you don’t know how many pears you buy versus apples, because you record it all under “fruit”.
On the other hand, taking care to define apples as apples and pears as pears gives you more control of the information about them while still allowing you to put them into the same, or even different, pies. You can now report that because of the ratio of apple to pear in your pie, the production cost will go up by 30%.
By the way, the corrollary is also true. Things are not different just because you treat them differently. A pear is still a pear whether you put it in a pie or a pudding or throw it at someone’s head.
To swing away from the analogy and back to the language of business architecture, this problem stems partly from the fact that a lot of people who work on BPM projects only understand the world in terms of process and everything is seen only through that lens. Separation of concerns is needed. The classification of a thing belongs to a separate domain to the activities that you can perform on that thing, or the decisions you can make about that thing, or the events that affect that thing.
This is something you need to bear in mind when working on Pega projects, because a Case Type in Pega represents what a Case is (data) and what you can do to it (process). I explore this further here.
Learn to see things for what they are and not just for how you treat them.
It’s not news to you that collaboration is key to success in many fields, so it might shock you, as it shocks Software Delivery Managers and Scrum Masters when I say: “I don’t care whether you deliver your software.”
OK, you got me, I do care because ultimately we are striving towards the same goal: realising some defined business benefit. There is an important caveat to my shocking statement: It only applies when I am working purely on the business architecture and not as a BA on the software development team, in which case I care a lot.
However, we all have to focus on playing our own part, so when I say: “I don’t care whether your deliver your software”, it’s mainly to shock some people into understanding that the realisation of a defined business benefit does not necessarily come down to the success about of one particular software project.
When I work on a technology-agnostic business architecture, I help the business understand and articulate what it needs, largely by modelling and testing those needs. I focus my attention on that purpose so that others who depend on understanding how the business needs to change can focus on their job. I do not concern myself with whether the change actually gets adopted – I leave that to the Change Manager. I do not concern myself with whether any consequent software gets delivered – I leave that to the Software Delivery Manager.
Business architecture is not about any one particular software project. Business architecture is essentially a set of models that describe how a business currently operates (As Is) or should be operating (I prefer the term “Should Be” over “To Be”). Implementing that Operating Model may require several software development projects (or even none); it may require a public relations campaign – in 2015 Ryanair’s changes to how it wants to operate involved a significant PR campaign; it may require a programme to train staff in new procedures and policies; it may require a programme of real estate sales and purchases and the consequent effects on staff, as at HMRC in 2016. Business architecture is bigger than any one software development project and it is certainly not about documenting software requirements, contrary to what many Product Owners and Scrum Masters assume (see “Business Architecture is about more than software requirements“).
That said, I have never met a Product Owner, Scrum Master or Software Delivery Manager who had ever seen a coherent set of business architecture models before, so their assumption that business analysis is nothing more than requirements elicitation is understandable.
My responsibility as a business architect ends once I have helped the business articulate and test its needs. I cannot also shoulder the responsibilities of other roles, such as to deliver the software that satisfies those needs. I make the same argument to change managers. It is up to them to deliver the needed changes that I have helped the business articulate.
Some see this as an unwillingness to collaborate. However, this is based on a misunderstanding of “collaboration”. Think of the medical staff who collaborate in an operating theatre: everybody has to focus on their own tasks in order for the whole team to succeed. However, the anaesthetist is not failing to collaborate for not grabbing a scalpel and mucking in with the surgeon.
It’s not just about understanding the boundaries of one’s own responsibilities, it’s also making sure you have the time to to fulfil those responsibilities.
Collaboration: know your job, do your job and thus help others to do theirs but let them worry about doing their own job.
I’ve worked on so many IT projects that this video could almost be an analogy for. Except in an IT project, leave people alone to get on with what they’re good at and everyone wins. Try to win by forcing others to fail and everyone falls over in a heap. In an IT project, there is no clever Aussie in the background. Everyone loses when one person tries to win glory for themselves.
This video contains profanity. Don’t watch it if that bothers you.
When it comes to describing business processes BPMN 2.0 is my notation of choice.
This post is about what I mean when I say “process model” and “process map”, so let’s not get hung up on the terms themselves. If you are an advocate of and expert in BPMN and you choose to call your models “maps”, I’ll die a little inside, but I won’t argue with you over your choice of term. Here I want to talk about rich language versus simplistic.
I’ve had many business analysts argue against using BPMN for describing business processes. I have always found it interesting that the ones who are argue against it, don’t know how to use it. One senior BA I interviewed for a client expressed great confidence in his ability to model processes using BPMN (which was a mandatory skill for the role) until he made a complete mess of an exercise I gave him. Suddenly he started arguing why the client should not use BPMN.
Most BAs I have met produce process maps rather than process models, so what’s the difference? In my experience, a process map is a simplistic flowchart that is not capable of expressing all aspects of the process. As I shall explain below, process maps simply lack the vocabulary to be adequately expressive. For me, one of the key points of a model is that you can testits robustness against a thorough set of likely scenarios. You model so that you can test before you implement. Bear in mind that implementation of a process does not necessarily involve software.
If you search online for images using the search term “process map”, you’ll see examples that contain as few as two different shapes. The most expressive I have seen contained 7 different shapes. The shapes are vocabulary.Make no mistake, such limited vocabulary does not make process maps “simple”, it makes them simplistic. The fact that something is easy to produce does not necessarily make it good. The fact that the limited vocabulary of process mapping allows anyone in a business to do it does not necessarily make it good. In my experience, business processes tend to be subtle and layered. The lack of expressiveness in process mapping cannot represent the true nature of the process. Against the advice of Albert Einstein, process mapping, in its attempt to be simple, surrenders the adequate representation of the business process.
Some BAs argue in favour of UML for modelling business processes. However:
“The OMG’s Unified Modeling Language® (UML®) helps you specify, visualize, and document models of software systems” (source)
I used to use UML activity diagrams for modelling business processes and stopped when I learned BPMN for several reasons. Firstly, because (per the OMG’s statement above) that’s not what UML is for; secondly, because they suffer from the same problem of restricted vocabulary; thirdly, because there is no standard vocabulary and grammar for activity diagrams.
Note, however, that I resisted learning BPMN at first. I suspect I wanted my experience up to that point to remain valid and relevant. Then I decided that the only way to truly choose was to learn both, so I did. Sadly, I have the impression that a lot of people these days would rather remain expert in an old way of doing things than invest in learning something new.
Unlike process mapping, BPMN 2.0 has a broad vocabulary of shapes and shape types that allows us to express the richness and sophistication of business processes as simply as possible, while ensuring the consistency of the use of that language through a standard grammar and syntax. BPMN doesn’t merely allow you to model the steps of a process, but also the nature of the steps (manual, user, automated, etc), the nature of what triggers the process (a timer, the receipt of a message, a human choice, etc), how the process must respond to different types of events that take place in the world, what to do if one of many parallel paths does not complete. These are just a few examples. What’s more, BPMN also allows us to build hierarchical models in three dimensions, as opposed to the two-dimensional nature of process maps. This is analogous to having a model of a town, showing the detail of every building, rather than just a map of it. One of the key things about BPMN is that it allows you to test the process.
In Waterfall software developments, business analysts often never find out that their simplistic process maps are not adequately descriptive because by the time everyone realises that the software doesn’t actually reflect the real business process, the people who produced the process maps have moved on and don’t learn the truth.
In Agile software developments, they can flesh out any lack of clarity in conversations but in my experience the clarifications get reflected in the screen flows of the software design while the original process maps are never refined. The result is that after the software goes into production, it and the process maps do not match, so the maps are useful neither for training nor as a reflection of the new “As Is”. This is largely down to people’s misinterpreting the Agile principle “Value conversation over documentation” as “Value conversation instead of documentation”.
Any modelling technique is a language and business processes are usually quite sophisticated. Would you rather learn and use a rich language to describe that sophistication, or would you rather stick with 2 to 7 shapes? Here’s the hidden bonus: a richer vocabulary enables richer thinking and better problem-solving skills.
BPMN 2.0 has a two palettes of shapes: Level 1 and Level 2. Learning Level 1 first allows process modellers to start getting to grips with the language. It also gives business people enough vocabulary to be able to start drawing initial drafts of models themselves, which can then be refined in collaboration with modellers who are fluent in Level 2.
For a slide deck tutorial on Level 1, click here. Anyone can learn it.
I admit it. I have a problem with user stories. Not with the Actor/Narrative/Benefit syntax or the idea of adding acceptance criteria or the idea of valuing conversation over documentation. I love all that. I have a problem with the name “user” stories.
I’ve been applying Agile principles for about ten years now and working in sprints for two years. However, I am not an Agile or Scrum guru, so I’m more than happy to be challenged by those who are.
My experience of working with Project Managers and Scrum masters is that they are very focussed on the delivery of a software solution; so much so that they don’t stop to consider that business architecture is not just about their software delivery project. In particular, they are focussed on what users want. My experience as a business architect tells me that what users say they want is not necessarily what the business needs and solving the problems of one user (or community of users) might well cause problems for people elsewhere in the business.
But it’s not just that. The word “user” constrains our thinking. Not all those who have a stake in the successful implementation of software are going to be users of that software. For example, take the owners of a particular business policy. Those stakeholders care about the decision logic behind that policy. They care that it is modelled accurately, tested thoroughly, understood universally and executed consistently. They care that any software that automates the decision logic does so correctly every time it executes. However, they themselves may well not be users of that software and yet they are the key stakeholders in the narrative of the story.
I still come across user stories of the following pattern:
As a [user role], I need to do X, so that X is done.
I do hope you can see the problem here: a mere restatement of the narrative does not articulate the business benefit. Users often cannot articulate the business benefit of taking an action because they are not the ones who are ultimately accountable for that benefit. They are merely responsible for taking an action on a screen that is supposed to result in that benefit. Here’s a tip, if robotics software could do the user’s job, then the user is probably not the right person to be asking about the business benefit.
In fact, I like the following format, as proposed on Crisp’s Blog:
So that [business value], as a [role], I need [narrative].
What’s more, not every business need requires a software or hardware solution. Some needs may be satisfied with changes that are procedural, organisational, location, staffing in nature or some other type of change.
Does focussing on the users of the software, rather than those who are ultimately accountable for the business benefit, cause us to fail to fully understand what that benefit is and why it is important to the business? I don’t know of any data that can answer that question definitively but I think the answer is “Yes” in at least some cases. This is why, as a business architect, I prefer to think of “business stories” rather than “user stories” and when the business person I am speaking to cannot articulate the business benefit, then I am speaking to the wrong stakeholder.
In 2012one of my readers contacted me to ask whether business rules and user story acceptance criteria could be considered the same thing. I answered in a blog post that they should not.
However, in 2013 I learned decision modelling, specifically, The Decision Model (TDM) and I was taught by Larry Goldberg and Barb Van Halle. More recently I have learned Decision Model & Notation (DMN) from James Taylor.
Decision modelling dramatically changed how I view business rules. In a nutshell, business rules are not particularly useful on their own. For example, if the business has a rule that a person must be aged 18 or over in order to have an account, that does not give us the full picture. What decision is the business trying to make when taking into account a person’s age? What other data (fact types) does the business take into account when making that decision? At which points in which processes can that decision be made? What other decisions take into account a person’s age?
A decision model takes into account all the fact types needed (there may be hundreds), organises them into logical groups (e.g., relating to a person’s health, employment history, credit rating, etc.), relates those groups to each other and shows how they all drive towards the decision that needs to be made. TDM also goes down to the individual statements (rows) of logic beneath the groups of fact types (DMN does not, although it doesn’t stop you doing it). Each of those statements of logic is essentially a business rule. The corresponding process model shows at what point the decision is made and what the consequences are.
Decision models sit within business architecture. They are a technology-agnostic business asset that not only state what the business’s logic is in relation to particular decisions, but they also allow a business to experiment with and test changes to the logic before deciding whether to implement those changes. Bear in mind that decision logic is not always implemented by software. It is often implemented directly by human beings; for example, when you ask shop assistant whether you may get a refund on a purchased item, the assistant implements decision logic based on certain fact types (purchase date, current date, whether the item was bought in a sale, condition of the item, etc), the company’s policy and consumer legislation.
Atomic tasks in process models are a good source of candidate user stories and since decision models correspond to atomic tasks (of type “business rule” in BPMN terms), for each one that needs to be automated we would have a candidate user story along the following lines:
As a [business role], I need the logic that allows me to decide Y to be automated, so that [expression of business value – this is essential, as it justifies spending money on automating the decision logic].
User stories are placeholders for conversations between the business and the people building and testing the software. In the case of a decision that is to be automated, the conversation needs to be about the logic of the decision. Of course, if the business comes to the conversation A) not knowing what the logic is and/or B) not having tested that the logic works, then it’s going to be a frustrating and fruitless conversation. The conversation needs to be about transferring trusted business logic to the software development team, not figuring out what that logic is.
That figuring out is called “decision modelling”. It sits entirely within the business domain and it should be done before the software implementation technology is even chosen. The logic should have been worked out and validated, and business test scenarios defined and executed against that logic. By doing so, when it comes to the software development sprint, all focus is on implementing the automation of trusted logic. Failure to do so means stepping into a sprint with unvalidated and untested business logic.
And so we come to acceptance criteria. Back in 2012 I argued that acceptance criteria were not business rules, rather they were test scenarios designed to check whether a software implementation executed business rules (in this case) correctly. My position on that has not changed. I’ve recently discussed this with Agile coaches and decision modellers and we agreed that acceptance criteria (for a decision model) are essentially the test scenarios that the business should already have executed against their decision model. However, because the logic behind a particular decision can be quite sophisticated, that sophistication must also be reflected in the corresponding test scenarios. Documenting all of them, potentially hundreds, as acceptance criteria within a user story strikes me as an unnecessary duplication of effort. Instead, I propose a single acceptance criterion to state that the software will be acceptable if it passes the same test scenarios that the business previously applied to the decision logic.
Not only does this approach avoid duplication of effort in documenting test scenarios, it also places the onus on the business to ensure that only tested logic goes into a software development sprint.
Collaboration isn’t some kind of Arthurian round table. It’s not about everyone having their say or having equal weight assigned to their say.
I have no time for the old style of business analyst who spends months crafting 3,000 pages of text (but not a single model) to describe requirements and then archives the document and moves on to another project. This “toss it over the fence” approach is the reason why so many projects that take a Waterfall approach don’t find problems with the analysis until they hit user acceptance testing (i.e., after a lot of time and money has been spent on the wrong thing).
I see the business analyst as the lynchpin between several stakeholder groups. After all, if the real business need is not identified and clearly articulated, how can the right solution be defined, built and tested? And don’t forget that the right solution might not be software.
So it is essential the BAs ensure they discover and articulate the business need, not just clearly and unambiguously, but also in a timely fashion. This means that as soon as they can articulate a need (whether via a process model, a decision model, a data model, or a textual description of something), they communicate that to all stakeholders. They don’t hold onto it until some massive document is ready to be reviewed (possibly weeks or months later). Moreover, if the need changes, or a better way to articulate it comes along, they communicate the changes immediately, without multiple cycles of reviews. By collaborating directly with the business (challenging their thinking, ensuring their needs support the strategic goals of the enterprise) to produce and test their models, reviews become unnecessary and the latest version is the approved version.
For me, in my professional environment, collaboration primarily involves sharing knowledge and the skills to define and access that knowledge. I might share a BPMN 2.0 process model. At some point before that, I will have shared the knowledge of how to read a BPMN 2.0 process model, even if that meant staying after hours to give tutorials.
However, collaboration does not mean a software developer or a project manager get to vote on whether I use BPMN 2.0 to model business processes any more than my role as a BA gets to vote on whether the developer uses Java or the PM uses MS Project.
I worked on a project where a team of BAs helped the business produce, validate and test models of their key decision logic. On the basis of the need represented by those models, a technical solutions provider was chosen. However, that solutions provider and the software development PM threw out the models because they didn’t want to spend half a day learning how to read them. I suspect they also didn’t like the idea of the business’s being able to manage its own decision logic independently of their technology suite. The result was not only the wasted effort and cost in producing the models in the first place but also that the business lost ownership of its own decision logic as it vanished into the dungeons of the software code.
In a truly collaborative environment, the business would have owned and prioritised the logic, the BAs would have decided how to model and test it (the latter in collaboration with test specialists), the developers would have decided how to implement the logic in the software and the testers would have decided how to QA that the software correctly implemented the logic expressed in the models. All stakeholders would have ensured that the others had access to any knowledge and skills they needed in order to fulfil their role.
There should be no L’Oréal system in place. Nobody is worth it, everybody must earn it and expertise in a particular area trumps opinion. Collaboration should not mean giving everyone an equal vote, unless they have the expertise to understand what they are voting for.
Perhaps you disagree. What are your thoughts? If I can’t defend my position, I’m open to adopting (or at least adapting to) yours.
Kind regards.
Declan Chellar
Post scriptum
You have read this far, which means you weren’t put off by the word “ochlocracy”. Chances are you had to look it up, as I had to when I first came across it two weeks ago. Even though I studied Ancient Greek at university, I didn’t recognise the root (όχλος – mob). It has astounded me over recent years how few people in the workplace want to learn something new, so the title of this post was aimed at eliminating those for whom it is too much trouble to learn even one new word. I acknowledge it smacks of pretentiousness and if I were to say “ochlocracy” in a meeting knowing full well that 90% of the people in the room would not know what it meant, that would certainly be pretentious. But in a meeting room, people can’t right-click on a word I say and look up its meaning – on a blog, it’s as easy as that. It didn’t put you off and I thank you for taking the time to look it up and read my post.
Most projects I’ve worked on have had a set of strategic goals that the project was supposed to realise. However, most people working on those projects could not say what the goals were or where they could be looked up.
Even on projects where the goals were stated and available, they were not always clearly articulated or well-structured. This post is not about analysing the business in order to identify the goals; it’s about putting structure on them once they have been identified.
I propose using the syntax of a Business Story to describe strategic goals. This syntax makes clear:
the business value of achieving that goal
the goal owner
the goal itself
the timeframe
If it’s not obvious to you, see Crisp’s Blog to see why I put the business value first.
Most strategic goals I have seen only articulate the goal itself, which is important. But to whom do we go if we need to discuss that goal? The owner (knowing the owner also tells us at what level within the organisation the goal is relevant). What tells us how long we have to achieve the goal? The timeframe. What tells us why the goal is important to the business? The business value.
There is more to it, however. We also need to know:
The relative priority of each goal
The impact on the business should a time-frame be missed
The date the goal was last reviewed with the owner
A list of inputs that were used in producing that goal (in case anyone wants to understand its background), such as:
This gives you a very simple tabular format that can be expressed in a slide, document, spreadsheet, wiki, Sharepoint page, or even just on index cards:
So that
State the business value in achieving this goal.
As a
State the title (not the name) of the owner of the goal, e.g., “Chief Operations Officer”.
I need
State the goal itself.
By
State the timeframe within which the goal needs to be met.
Priority:
State the relative business priority of this goal.
Impact of Miss:
Detail the expected impact on the business should the time-frame be missed.
You are probably familiar with the Agile Manifesto that was written in 2001 by several forward-thinking software developers.
However, it is a manifesto for software development and, as you may have seen in a previous post, business architecture is about more than software requirements. Does that mean we cannot apply the 12 principles behind the Agile Manifesto to our work as business analysts? In fact we can, and we should. Here is my adaptation of the principles, with changes in bold italics.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable models of the business.
Welcome changing requirements, even late in development of the models. Agile processes harness change for the customer’s competitive advantage.
Deliver models of the business frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business expertsand analystsmust work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within an analysis team is face-to-face conversation.
Tested models of the businessare the primary measure of progress.
Agile processes promote sustainable development. The sponsors, analysts, and business experts should be able to maintain a constant pace indefinitely.
Continuous attention to excellence in analysis techniques and good businessdesign enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best businessarchitectures, requirements, and businessdesigns emerge from self-organising teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Producing software in an agile and iterative fashion has many benefits, as long as you are producing the software the business actually needs (and drives it towards achieving its strategic goals), rather than what individual users say they want. How do you know the business’s acceptance criteria are the right ones?How do you know the backlog of user stories is internally consistent?Producing business architecture in an Agile fashion is what drives out a robust backlog of user stories, with the right business knowledge to be able to define the most appropriate acceptance criteria (see my earlier post: Business analysis is about more than software requirements).
