Identifying User Stories and Deriving Acceptance Criteria

Most Product Owners I have met do not have a method for identifying candidate user stories or deriving acceptance criteria for those stories.

CAVEAT: I believe you should only model to the level of detail needed, regardless of what type of model you are using. If the team were building a process to allow employees to claim back business expenses, I would not spend a lot of time modelling the process because the process itself is unlikely to be complex. However, I have never worked on a project where the processes were not complex and I have found that it is the process models themselves that tell you what your candidate user stories are (although not all of them will come from process models). This blog post is in the context of complex business operations.

I have been on a few projects now where the Product Owners were new to the concept of user stories. In some cases, the POs received no training at all prior to taking up their role and had no Agile Coach to guide them.

My experience is that when the user story is the only technique available to POs and BAs, avoidable misunderstandings always come to light during playbacks, testing and even in production. Yes, I know Agile is meant to allow you to quickly iterate and enhance but that is too often used as an excuse not to do any analysis or planning.

User stories do not exist in isolation from one another. When user stories are plucked out of conversations with users about complex business operations instead of being derived from models of those operations, you can be left with a jigsaw puzzle instead of a picture of those operations. Yes, you can put the picture together from the pieces but the whole idea of a puzzle is that it is meant to be difficult and take you a long time. Who wants to build business operations and software like that?

This “puzzle” approach leads to some or all of the following problems:

  • Not identifying all the user stories
  • Identifying some wrong ones
  • Not fully understanding how the user stories relate to each other
  • User stories that negatively impact each other (one user not knowing or caring about another user’s needs)
  • User stories that do not support the strategic goals of the business or, worse, contradict those goals
  • User stories being written from the PO’s or BA’s perspective (“As a BA…”) instead of the business perspective
  • User stories missing the value statement (“So that…”) – missing because it was not understood or, worse, the user story added no value to the business
  • Missing acceptance criteria
  • Incorrect acceptance criteria

The way a real jigsaw puzzle is produced is analogous to the approach you should be taking: you have the picture first and then you break it up into pieces (user stories). The only difference is that understanding where each piece fits should subsequently be easy, not puzzling.

My approach is like that. You make a picture (it can be a simple sketch or a life-like oil painting, depending on the need) and you use the picture to decide what pieces you need. Whenever someone needs to know the context of any particular piece, they hold it up against the picture. End of analogy.

Here is my approach, in brief:

  1. Consider each atomic task in a business process model draft as a candidate for a user story. This won’t always be the cause, as some tasks can be grouped into a single user story:
    • The label of the lane in which the task appears often (not always, sometimes the task beneficiary is not the task performer) gives you the “As a…” clause.
    • The label of the task becomes the “I need” statement.
    • The business value that you documented as meta-information about the task (I hope you did that) becomes the “So that…” statement.
  2. Based on how the process flows within your model, draft test scenarios:
    • Your test scenario will cover several atomic tasks and so several user stories.
    • Use a phrase such as “Verify that…” for each test point in your scenario.
  3. Draft the training material (if you’re required to do so).
  4. Amend the process model if the test scenarios and training material reveal flaws.
  5. Each “Verify that…” phrase becomes a candidate acceptance criterion in your candidate user story.
  6. Iterate.

</ collaborate>

A certain amount of this work needs to be done before any software development project starts, otherwise you have no initial Product Backlog. You don’t wait until the models, scenarios and user stories are perfect and complete because they are never perfect and complete. However, you need to get them to a state where they are good enough to act as a foundation for the current project and as a baseline for future enhancements.

Anyway, that is my method. It is not the method but it works for me and it is certainly better than no method.

Do you have another method that works?

Kind regards,

Declan Chellar

The copyright of this blog post belongs to me, Declan Chellar, you may not reproduce any part of it without my written permission.


Visit Us
Follow by Email

Pega Case Life Cycle Model – Part 3

In Part 2,  we compared how a Case life cycle might look in Pega’s Case Life Cycle Designer versus BPMN. Here, in Part 3, we’ll consider when you should and should not use Pega’s Case Life Cycle Design tool to model the business process.

As we have seen, if you are working on understanding the business process, a model in BPMN gives you a much more ‘joined-up’ view. Ideally, by the time you get into the high level design of your Pega solution, the business will have already worked with appropriately experienced business analysts to produce models of their “To Be” business process in BPMN and those models will be the input to your Pega design. In fact, they should be an input to the Inception phase.

Despite the fact that BPMN has been an international standard for modelling business processes for more than a decade, my experience is that most BAs don’t yet know how to use it and so it’s unlikely that a business will provide robust process models as inputs to the Inception phase of your project. However, even if the business does provide robust process models, a corresponding Pega Case Life Cycle Model (CLCM) is still not necessarily advisable.

When should you consider not producing a CLCM?

You need to model an entire business process and not just the tasks that are to be implemented in Pega.
If you need to show activities that are not to be implemented in Pega, do not model the business process inside Pega. This has been true since the very first version of PegaRules more than a decade ago. You can only show in a flow rule, what is to be implemented in Pega. You can only show in a Discovery Map what is to be implemented in Pega. You can only show in a Case Life Cycle Model what is to be implemented in Pega. I have known some inexperienced BAs who have modelled activities that were not to be implemented. I have even known Certified Pega BAs who modelled, as alternative paths, functionality that was to be implemented at some point in the future, thus revealing a fundamental lack of understanding of both process modelling and Pega itself.

The business entity represented by a Pega Case can be acted on by more than one business process.
It is very important to remember that Pega tightly couples the data of a Case with the tasks that can be performed on that Case. There is no distinction. A Pega Case is both its data and its activities. However, in business architecture the definition of the characteristics of a thing are separate from (but linked to) the definitions of the one or more processes that can act upon that thing. This is what we call “separation of concerns”. If your case is a simple one, such as the expense claim example in the Pega BA and SA training courses, and only one business process can act on it, then the CLCM may be an appropriate modelling tool. However, the CLCM cannot show how more than one business process can act upon a business entity.

The business process does not require any human intervention.
A Case in Pega must have tasks that are assigned to a human to perform. If the business process requires complete automation of tasks (even if the process is started by a human), then a CLCM is not the right modelling tool.

If your business process cannot be represented by a CLCM, it doesn’t mean it cannot be implemented in Pega. Far from it, Pega is a very good tool for implementing automated business processes. Your job as a BA is to articulate the business need clearly, unambiguously and concisely. If you do that with tools and techniques other than Pega’s CLCM, rest assured that the Pega LSA will design a good technical solution.

However, if your only background in doing analysis for a Pega project is the Pega BA training course, you are likely to force your business process(es) into the CLCM when it is not appropriate, you will imply things that will confuse and misdirect the LSA, leading to delays and a dissatisfied customer.

Remember that the Pega BA training course is an “essentials” course, not an exhaustive one.

Regardess of whether a CLCM is appropriate, if the business does not bring robust process models to the table, my recommendation is that you take some time to work with the business to produce them. I would first establish the scope of the target process or processes. See the link at the end of this post for a tutorial on how to do that. In the case of a straightforward process such as the ‘Manage Expense Claim’ process we saw in Part 2, I hope you can see that it would only take a few minutes to produce the high-level view of the process in BPMN; there wouldn’t be a significant delay in producing the CLCM in Pega and you would have more confidence that the model in Pega represented the real business need. In fact, one person on the team could model the life-cycle in Pega while the BA models it in BPMN, so there would be no delay at all. This is akin to what Pega calls a “Real-time Whiteboard” session. Indeed, one of Pega’s criteria for deciding whether to run such a session is that the scope is less complex. However, if you didn’t get an accurate view of the complexity of the scope in the first place, you may mistakenly decide to use a “Real-time Whiteboard” or even “Real-time Capture” session and then find you are trying to build a prototype for a process that you don’t understand.

If the business area is much more sophisticated, such as the processes to handle a tax fraud case, there is all the more reason to model the processes in BPMN because you don’t want to get too far into your technical solution design before discovering that you haven’t understood the business process (or that the business people didn’t explain the process well).

Other advantages of modelling processes in BPMN before (or, less ideally, at the same time as you model the life cycle in Pega):

  • You can show the entire business process and not just the activities that will be implemented in Pega
  • You can show the business events that can impact the process
  • You can show the interactions between your process and other processes / external entities
  • You can link your process models to other artefacts in the business architecture, such as, business glossary, decision models, event models, role definitions, etc.

If you do decide to produce a model using BPMN (or the customer provides one), don’t forget to attach each version of the model to the Specification in Pega that corresponds to your Case Type.

Kind regards.

Declan Chellar

Related posts:

Visit Us
Follow by Email

Sizing process complexity

A lot of people think the complexity of a process is about the number of stages and steps it has but it’s not.

I have often seen BAs do an initial analysis of a business process by producing a diagram like this:

This is fine, as long as you have already established the scope of the process (see the end of this post for a link to a tutorial on that) and you are planning to elaborate the process beyond this simplistic diagram. Unfortunately, I have been on projects where the BA thought that was enough. A poor way to understand the complexity is simply to count up the number of stages and steps. However, a process is more than a count of its steps. The real complexity from a software implementation point of view lies primarily in two things:

  • The decision points throughout the process
  • The points where any software you are going to build will need to interface with other software systems

Any other steps are going to be about gathering data either to make decisions during the process you are modelling or to send to other processes or display data to the user.

I won’t go into interfaces because they are for the technical solutions architect to explore (although the BA may be involved in identifying those interface points). In any case, if your process model is technology-agnostic, then interfaces will not be relevant yet.

The significance of decision points is often overlooked, however, largely due to a lack of awareness of the power of decision modelling. Most BAs I’ve met still think in terms of business rules, instead of decision logic. Moreover, they often start thinking about business rules too late. As soon as you have defined the scope of the business process, you should ask the business what key decisions need to be made within each process stage. At this point, the order of them is not important. It’s unlikely the business will be able to remember every step that needs to be performed in the process but it is quite likely they will remember the important decisions that need to be made.

You need to understand two things about a business decision at this stage in your analysis:

  • Roughly how many outcomes it can have
  • Roughly how many data items are needed as inputs

This information is enough to be able to ‘t-shirt size’ those decisions. I don’t have a formula for calculating the complexity of a business decision based on those two pieces of information but I’m sure you can see that a decision that can produce two possible outputs based on three inputs will be a lot simpler to analyse, model, test and implement that one that can produce five possible outputs based on 300 separate input data.

The technical solutions architect will size any interface points and you can produce something like this:

In this example, the zeroes represent steps that just gather or present data, while the ambers and blues represent decision points and interface points.

When asking the business to identify the decisions they have to make, help them identify hidden decisions, i.e., ones that they are so used to making that they don’t give them much thought. Examples could be: duplicate checks, whether to send an email, how to determine what data to put in that email, data validation logic, etc. In a loan application process, don’t assume that the only decision being made is whether to approve the loan.

Taking a decision-focused view of the business process will reveal the true sophistication of the process.

Kind regards.

Declan Chellar

Related posts:

Visit Us
Follow by Email

Pega Case Life Cycle Model – Part 2

In Part 1, we went through some of the key terms Pega terms in Case Life Cycle modelling. Here, in Part 2, we’ll compare modelling a Case life cycle using Pega 7’s modelling tool with BPMN 2.0.

The life cycle view of a Case in Pega 7 is similar to the Discovery Map in Pega 6.

Case lifecycle example in Pega 7

However, other than the sequence of the three primary stages, it is not possible to show the flow of the life cycle in Pega 7. If you are using it as a high-level technical solution design tool, that’s fine, but it conceals too much of the process flow to be useful in gaining (and displaying) an initial understanding of the business process. As an analysis tool, it has the same weaknesses as its predecessor, the Discovery Map. In this model, it’s not explicit that ‘Review Claim (2)’ is actually an alternate path. Moreover, while you can see that ‘Approval Rejection’ is an alternate stage, you cannot see where it branches from the primary.

Using BPMN, however, you can see at a glance the high-level view of the entire life cycle, what the key stages are, what the primary path is (which I have marked in blue below), what roles are involved, what the alternate activities are (in grey) and what the business exceptions are (in pink) and then drill down into the sub-process according to your audience.

The high level view of the 'Manage Expense Claim' process in BPMN.

Even with this high-level overview of the business process, you can start to build test scenarios to make sure the process works at a business level before implementing anything in Pega. I’m a big fan of testing the business logic before you implement, so that when you test the software, you are testing only that the software works and not that the business logic makes sense.

Notice that I have re-used the sub-process “Review Expense claim”. Any differences can be handled by alternate paths in the child diagram or in the logic of any decision points in the child diagram. In the Case Life Cycle Model, such re-use is not obvious, nor even suggested. The fact that “Review Claim (1)” and “Review Claim (2)” are labelled differently means they are different processes in Pega.

In Pega 7, you can model the flow of a particular path through a particular Stage (remember, this is what Pega calls a ‘process’). Take the ‘Review Claim (1)’ process from the Pega life cycle model above, for example:

Pega Flow Rule

Here is the corresponding diagram for the ‘Review Expense Claim’ sub-process in BPMN:

Review Expense Claim sub-process in BPMN.

I’m sure you can see that if you gave that diagram to Pega developers instead of a textual use case, they would find it much easier to understand what flow to build.

This sub-process diagram covers both Pega processes “Review Claim (1)” and “Review Claim (2)”. How? By handling the difference inside the decision logic for the task “Determine Further Review Required”. In essence, one of the factors taken into account by the logic is the user’s business role; if it is “Director”, then a further review is not required.

Note: in Pega flows, the diamond shape represents a Decision Rule that holds the implementation of the decision logic. In BPMN, the diamond shape (called a ‘gateway’) simply interrogates the outcome of the decision logic, while a model of the logic itself sits in a Decision Model behind the corresponding ‘business rule’ task (in this case, ‘Determine Further Review Required’).

Here’s an important point for traceability: I would add a Specification in Pega of type User Story to represent any atomic tasks in the BPMN model. In the case of ‘Determine Further Review Required’ the actual business logic I would model and test in a Decision Model of the same name. The logic (business rules) in the Decision Model would essentially be the requirements. Neither a Process Model nor a Pega Specification is an appropriate mechanism for modelling business logic. Any Decision Rules in Pega could be traced back to the Decision Model via the relevant Specification and the ‘Determine Further Review Required’ activity in the Process Model.

I hope you have found this post useful. Thanks for taking the time to read it. For bonus points, have another look at the second BPMN diagram above (click here if you don’t want to scroll back up) and tell me:

  • Why I assigned the Business Rule type to the task ‘Determine Further Review Required’
  • Why I assigned the Service type instead of the Send type to the ‘Notify Employee’ tasks

In Part 3, we’ll consider when you should and should not use Pega’s Case Life Cycle Design tool to model the business process.

Kind regards.

Declan Chellar

Related posts:

Visit Us
Follow by Email

What is a Business Architect?

Some years ago, I was asked: ‘What is the difference between a Business Analyst and a Business Architect?’

My reply was that a Business Architect was someone who can apply the techniques of business analysis to an architectural framework in a technology-agnostic way. There are other differences but that was what occurred to me at the time.

However, that led me to ask myself: ‘What is a Business Architect?’ I think there are two types, broadly speaking. One would be someone who can truly shape a business and decide, or at least advise, what its business model should be, what strategies it should put in place and what it needs to do to implement those strategies. I am not that type of business architect. That kind of strategic advisory role requires deep knowledge and insight into a particular business and a particular industry. However, the people with that knowledge often lack the formal language/framework to model their ideas. As the poet John Ciardi said: “The language of experience is not the language of classification” (which is why, on software development projects, simply writing requirements in business language so often leads to business people saying during UAT: “Yeah, but that’s not what we meant”).

My area of expertise is the language of classification, or, rather, languages because each modelling technique is a language of sorts with its own vocabulary, grammar and syntax. Modelling techniques also allow variations in method and style, which are effectively dialects. In other words, I am a technician, not a strategist. I am a ghost writer. I cannot tell you what your strategic goals should be but I can help you put structure on them to make them clear and unambiguous. I cannot tell you what your business model should be but I can help you describe it formally in the language of the Business Model Canvas. In asking you the kind of questions the rigour of the canvas demands, I can help you articulate things that are so normal to you that you wouldn’t otherwise have thought they needed to be articulated, or help you think of things you wouldn’t otherwise have thought of at all.

Business Architecture is typically defined as:

‘A blueprint of the enterprise that provides a common understanding of the
organization and is used to align strategic objectives and tactical demands.’

With that in mind, I would say the strategist provides the content of that blueprint, while the technician provides the form. Ideally, an organisation would have a Business Architect who is a combination of strategist and technician but a strategist would likely not have the time to gain experience in the detail of technical models of the 2nd row of the Zachman Framework. On the other hand, a technician would not likely have the time to gain the business experience. However, their experience and skill sets are complementary. In fact, my view is that the 1st row of the Zachman Framework is where the two types of Business Architect mostly collaborate.

If I were to be precise, and those who have worked with me know that is one of my strengths, I would label myself a “Business Architecture Analyst” in that I analyse the architecture of a business, rather than the business itself.

Well, I’m glad I cleared that up.

What are your thoughts?

Kind regards.

Declan Chellar

Visit Us
Follow by Email

There should be no legislation against ‘hate’ crime

I hope that got your attention. However, this post is about defining terms well so that your business architecture and how your business operates does not get bloated simply because people conflate different concepts.

I’m using the concept of ‘hate’ crime because I happen to be discussing the topic with someone on Twitter and it illustrates an important point about modelling business concepts.

Having seen a tweet decrying the fact that Ireland does not have any legislation against hate crime, I tweeted: ‘I don’t understand ‘hate crime’ laws. If someone [intentionally] stabs me, should it matter whether they hated me or not? Feel free to educate me.’

Moreover, if someone stabbed me, I would not want them to receive a different punishment based on whether their motivation was my skin colour, or the fact that I’m bald, or robbery, or anything else. I would certainly want the motivation to be recorded, however. By the way, I was assaulted once, by someone who made it clear with their words that the motivation was my skin-colour.

In response, I was sent the following argument:

Yes, it does matter. Obviously, any crime impacts on a victim. Hate crime has further impact as hate crime victims imply assert that their experience was an unlucky occurrence (wrong place, wrong time), they are forced to accept that their identity was targeted and they remain at risk of repeat victimisation. Fear of being targeted impacts on the way people live their lives, with victims changing the way they live, limiting their use of public space, etc. Hate crime’s ripple effect is also significant. As well as impacting on the victim, it sends a message to that community.

It would seem, therefore, that the intent is to acknowledge the motivation for the crime and to use that knowledge to educate victims and society at large and to enable us to tackle the root causes of such motivations and therefore the crimes themselves.

However, to achieve that, you don’t need separate legislation against attempted murder and attempted murder because the perpetrator hates, say, people with brown skin. You simply need to be able to record the motivation for the crime against the crime itself. One crime on the statute books, many possible motivations for that crime. That would be sufficient to provide the data needed for education and prevention programmes.

Having separate legislation for each motivation has several disadvantages without improving data for education and prevention:

  • Increased statutes and the corresponding time and effort involved in debating and adding such statutes
  • Operational overhead in having to add a new statute each time a new motivation is uncovered (as opposed to simply adding a new motivation to an existing statute)
  • Risk of allowing different levels of sanction against the same crime for different motivations

For those who want particular hate crimes, or hate crimes in general, to be addressed, it would be quicker, more effective and cheaper to campaign to have a new motivation added to crime reporting than to have a new statute added.

Actions and the reasons for those actions are related but distinct. Modelling them as the same thing makes for inefficient and ineffective operations, whether in terms of criminal statutes or business operations.

I have another reason for being against “hate” crime legislation. Once you allow the government to criminalise hate itself (as opposed to actions, probably already illegal, motivated by hate), you allow the government to define what constitutes “hate”. Do you really want to open a door that could allow the government to define criticism of a minister as “hate”?

Is there a flaw in my reasoning? Let me know. If you can sell me your argument, I’ll spin on a sixpence.

Kind regards.

Declan Chellar

Visit Us
Follow by Email

Review of the PegaBPM Methodology

In this blog post I aim to provide an appraisal of the Pega Developer Network articles “What is the SmartBPM Methodology?” and “Using Pega BPM with PRPC“, based on my experiences working on Pega projects in the field.

I am a Certified Pega Business Architect (7.2) and Pega Methodology Black Belt, and here I provide an alternative to SmartBPM (now known as PegaBPM), which I hope addresses what I perceive to be the shortcomings of the methodology. This post addresses the SmartBPM methodology only and not the Pega Scrum methodology. Moreover, it does not address techniques specific to any discipline (e.g., use case modelling).

Note that Pega clearly states that the SmartBPM methodology “is not a concrete prescriptive process”, that it is adaptable and that the phase information is an outline only. Therefore some of my suggestions are nothing more than an adaption of the methodology and others merely add detail to what is currently in outline form. However, other suggestions are the result of the problems I see with the original PDN article or with the methodology itself. You can download the full appraisal in PDF form from the link below, but here are what I consider to be the critical flaws in SmartBPM.

Continue reading Review of the PegaBPM Methodology

Visit Us
Follow by Email

Pega 7.2: business objectives, requirements and specifications

If you are a Pega Business Architect, you will be familiar with Pega’s feature that lets you connect Business Objectives, Requirements and Specifications.

This feature is excellent for traceability but it may surprise you to know that I don’t use it exactly the way Pega tells you to.

Business Objectives

‘Business objectives illustrate how the Pega application delivers value to the business’1

It’s important that everyone on a Pega development understands what value they are trying to deliver to their customer because software delivery is not an end in itself, it is merely a means to the true end, which is realisation of the desired business benefit (which should be stated in the business case and encapsulated in the Business Objectives). Yet you’d be surprised at how few projects (in my experience) actually document Business Objectives in Pega. I’ve even worked on projects where no one on the team could tell me what they were or where they were documented. Not only do I document them, I also like to print them out and stick them on the wall so everyone keeps sight of them. Pega encourages you to keep Business Objectives SMART, which is absolutely correct, and provides you with the means to capture them:

However, I have some reservations. Firstly, any Pega project I’ve been on has had a wider scope than the Pega solution, usually involving other technologies as well as non-technological business changes, so there will be Business Objectives which are important to the success of the change initiative but which are not relevant to the Pega solution. Thus it makes no sense to make Pega the golden repository of Business Objectives, rather, I would document the Business Objectives in the business architecture repository and put a reference in Pega to the ones relevant to the Pega solution.

Moreover, while you can write a SMART one-liner, I like to put a lot more meat on strategic business goals. Click here to see what I mean.


‘One or more requirements define the criteria for the successful implementation of a specification.’2

Pega allows you to capture Requirements via the following form:

This form has hardly changed at all since Pega first introduced DCO in 2008. That’s not a bad thing in itself because many organisations still develop software the way they did in 2008 and the tool caters for that. In any case, if you don’t think it’s broken, why fix it?

My preference these days is to work with User Stories rather than Use Cases. The Pega Specification (see below) allows you to document either User Stories or Use Cases. The statement above, talks about Requirements as if they were User Story Acceptance Criteria, which they are, in my opinion, if you are taking a User Story approach.

The main problem I have always had with the Requirement form in Pega is that there is no way to indicate which Business Objective the Requirement is supposed to support. If you are following Pega’s methodology, you first document Business Objectives and then an initial set of Requirements. However, since you cannot link the two directly, the opportunity for scope creep is there. I suspect this lack of linking is also part of the reason people often ignore Business Objectives.


‘Specifications use business language to describe the steps needed to meet a requirement.’3

That’s what Pega says Specifications are for but it’s not what I recommend. Pega allows you to document Specifications as either Use Cases or User Stories and since my preference is for the latter, let’s stick with that. I prefer Mike Cohn’s definition of a User Story:

‘User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.’ – Mike Cohn4

I also like the description of User Stories as ‘placeholders for a conversation’; that being the case, a Specification in Pega is effectively a useful placeholder for anything you care to document about that conversation (business background, diagrams, acceptance criteria, technical solution designs, risks, assumptions, links to further useful information, etc.). Remember, Agile principles promote conversation over documentation, not instead of documentation.

Notice that it is a Pega Specification that you link back to a Business Objective (unfortunately, only one), so although the sequence of creation is supposed to be: Business Objective –> Requirement –> Specification, the mechanism of traceability is, in fact: Business Objective –> Specification <– Requirement.

 Notice that you can document both Acceptance Criteria and Requirements against a Pega Specification of type User Story:

 As I said, I consider the Acceptance Criteria of a User Story to be Requirements and judging by Pega’s definition of the purpose of Requirements (‘requirements define the criteria for the successful implementation of a specification’), perhaps they would agree. Therefore, I would not add both Acceptance Criteria and Requirements to my Pega application. Instead I would:

  1. Document Business Objectives
  2. Add User Stories from the customer’s Product Back Log in the form of Specifications
  3. Document Requirements or Acceptance Criteria against those Specifications

Note that if you document Requirements as Acceptance Criteria, you only get to add a single line of text. However, if you document Acceptance Criteria as Requirements, you get the richness of the Requirements form (see above).

Although my approach is not how Pega’s training says to do it, it does give you traceability from the outset: Business Objective –> Specification –> Requirement / Acceptance Criterion

Full credit to Pega for not enforcing their way of doing it. That’s the right approach to methodology: adapt it to your needs.

What have your experiences been?

Kind regards.

Declan Chellar

Visit Us
Follow by Email

Deriving Business (User) Stories from your Business Architecture

For any kind of enterprise-wide change initiative, if you derive your backlog of Business Stories only from interviews with users, you may to end up with a patchwork of individual needs that don’t necessarily hang together, some of which will conflict with each other and which won’t give you the enterprise picture.

If you don’t already know why I say “Business Stories” instead of “User Stories”, click here for some pre-reading.

Some time ago I worked on a programme that was already in sprint 8 of its software development by the time I joined. Two large walls were plastered with index cards representing Epics and User Stories. Considerable time was spent daily on re-arranging those cards, involving at least two senior business analysts and the Product Owner. After a week, I asked what they were doing and I was told that they were trying to organise the cards so that they represented the relevant business processes. My response was something along the lines of: ‘Surely the business architecture that drove out these stories already shows the relevant business processes.’

I admit, I knew there was no business architecture and that I would get blank looks but I wanted to make an important point, which is that you should derive your initial Product Backlog from your business architecture, not try to reverse-engineer your business architecture from a bunch of User Stories.

That conversation led to another one with the Product Owner and not long afterwards I was asked to work in parallel with the software development project to help the business define its technology-agnostic architecture and use that to verify whether the Product Backlog contained the right stories.

It turned out that many of the stories were wrong, or duplicated other stories, or conflicted with other stories and that no amount of re-arranging the index cards was going to tell the over-arching story: “What is the very nature of this business for which we are spending millions on software development?”

One of the key things missing was a common understanding of the strategic objectives of the programme. I eventually managed to trace down a list of them in a slide deck attached to an email (that’s right, not in a repository where anyone could find them easily). They were poorly worded, with no indication of who owned each goal, what time frame was needed or what the business value was. In fact, a set of well-structured business goals should be the starting point of your Product Backlog.

Also missing was an understanding of the business taxonomy. The organisation involved had thousands of employees, all of whom originally came from other parts of the enterprise. To use fruit as an analogy, some said ‘mandarin’, while others said ‘clementine’, when they both meant ‘orange’, so there was some duplication of user stories that was not obvious either to the Product owner or the senior business analysts. In other scenarios, multiple groups said ‘apple’, when one really meant specifically ‘granny smith’, others meant ‘royal gala’ and yet others ‘bramley’, so in some cases there was only one user story when several were needed and, again, that was not obvious either to the Product owner or the senior business analysts. In some areas of the business it was even worse: they didn’t know whether the concepts they were talking about were apples or oranges or even whether they were fruit at all.

By the way, this lack of consistency when it comes to naming and defining important concepts is common in organisations where ‘dialects’ develop over time as the enterprise grows, especially if that growth is due to acquisition of other companies. A well-formed enterprise-wide business taxonomy is an essential lingua franca.

A robust (by which I mean mature, tested but open to change) business taxonomy will suggest many candidate Business Stories. All you have to do is look at each thing defined in the taxonomy and ask whether key roles need to be able to CRUD it and you end up with candidate Business Stories along the lines of ‘So that [business value], as a [role] I need to be able to [create/read/update/delete] a [business concept]’.

Another problem on that programme of work was a total absence of business process models, which is why the senior BAs were trying to reverse-engineer processes from the Product Backlog. In fact, robust process models suggest candidate epics and stories. You could argue that a whole process can be represented by an epic. You could also argue that a particular path through a process can be represented by an epic. Either way, once you get down to atomic activities in your process model, you have candidate stories. The role represented by the relevant swimlane suggests the actor in the story (caveat: but not always), while the label on the activity itself suggests the narrative. The only thing missing from the diagram, although it should still be accessible as part of the meta-information of the model, is the business value of performing that activity.

These are the main examples of how your business architecture can be used to drive out a candidate backlog of epics and stories. Sometimes further analysis will reveal stories that aren’t covered by anything in the business architecture, in which case you update the models of the architecture to reflect the new understanding.

How do you derive your initial enterprise-wide Product Backlog?

Kind regards.

Declan Chellar

Visit Us
Follow by Email

Pega Case Life Cycle Model – Part 1

Pega 7’s case life cycle modelling tools enable you to quickly model and demonstrate a high-level process design within Pega in front of your customer.

The tools I’m talking about are the life cycle view of a case type and the flow view of a process within a case type. While these are useful tools for the high-level technical solution design and, importantly, getting your customer on-board with that design, I do not see them, strictly speaking, as business analysis tools.

Here, in Part 1, I explain some terms for BAs who may be new to Pega.

Case Type
You may think this is analogous to a business entity, especially when you see examples of Case Type names as noun structures, e.g.: Expense Claim, Vacation Request, Loan Application, Customer Order, etc.. The reason we use noun structures in data models and business glossaries is to emphasise the static nature of the model and to allow us to fully understand what something is separately from how we process it. However, the Pega glossary definition of a Case Type uses the language of process: ‘A case type represents work in your application that follows a life cycle, or path, to completion (the bold type is my emphasis).

If you’ve taken the Pega BA training course, you may remember the training material says: ‘A case type is a type of artifact in Pega used to define the tasks and decisions needed to resolve a case’ and ‘Case types model how and when work gets done‘ (the bold type is my emphasis). Pega also says a Case ‘delivers a meaningful business outcome to a customer, partner, or internal stakeholder’.

If you’re a business analyst new to Pega, these statements might strike you as more akin to definitions of a business process (hover here to see my definition), whereas you might understandably think of a ‘Case’ as a business entity. Indeed, the Case Designer in Pega is essentially a tool for designing the high-level implementation of a process. So when you are discussing Case Types with your team, be aware that it has a data model aspect (the What) and a life cycle aspect (the How). That Pega wraps the what and the how together in the Case Type has an impact on how you choose to model the business, as I shall explain in Part 3.

In Pega terms, a Stage ‘is the first level of organizing work in your case type’. You may by now have studied my slide deck on defining process scope, in which case you will know that my first iteration of a process model only addresses the Key Stages of the process. This is the highest level view of how a process breaks down into activities. This is similar to what Pega calls a ‘Stage’. One main difference is in the naming convention. Pega uses a noun phrase, whereas I use the BPMN convention of modelling key stages as sub-processes, thus I name them with verb phrases.

Another important aspect of a Stage in Pega is that each stage typically represents tasks performed by a different role. For example, an expense claim can go through submission, review and payment stages, with the Case assigned to a different role at each stage. At the very least, a Stage is one or more Processes (see below) that must be completed before then next stage can begin, even if only one role is involved.

This concept of a Stage in Pega is inseparable from the concept of a Case. This also has an impact on how you choose to model the business.

In Pega terms, ‘processes are organized within [my emphasis] stages and define one or more paths the case must follow’. In other words, in Pega, each possible path through a Stage is a separate process. Here is an important difference in language between a business analyst trained in process modelling using BPMN and a Pega business analyst.

In BPMN a Stage is a sub-set of a Process. In Pega 7, a Process is a sub-set of a Stage.

In Pega 7. the terms ‘alternate’ and ‘exception’ are synonymous. ‘Use alternate stages to organize the process steps used to manage exceptions from the primary path’. To my mind the word ‘alternate’ refers to a different way to achieve your original objective; it’s a deviation from the normal path but you still end up where you wanted to go. An ‘exception’, on the other hand, deviates from the normal path but does not lead you to your desired outcome. Be aware that many software developers only use ‘exception’ to mean technical exceptions (e.g., what to do when a particular system doesn’t respond to a request), rather than business exceptions.

In Pega 7, a Participant is an actor who performs activities. The term for this in BPMN is Performer. A Participant in BPMN is an entity (external to your process) or another process, that interacts with the process you are modelling.

I’m not pointing out these differences as a criticism of Pega but to make you aware of them, so that when you hear Pega Systems Architects using them, you don’t get confused.

In Part 2, I’ll compare Pega’s Case Lifecycle Model with BPMN 2.0.

Kind regards.

Declan Chellar

Related posts:

Visit Us
Follow by Email