Skip to main content

Tag: Use Cases

The Story Behind User Stories

Starting off my new role as a Business Analyst, I have had a week-long refresher course on the ‘right’ way to write User Stories.

‘Right’ in quotes, because there really is no right or wrong way to write a User Story. All you have are a set of guidelines and common practices, all of which are only tried and true methods as experienced by your peers.

A User Story is somewhat of an enigma. Primarily, it is meant to be a way to communicate requirements to developers so that they know what to build.

However, at the same time, User Stories must also express to the business why this feature is being built and what business value it promises to deliver.

The fact that a User Story has two sets of very different audiences, one technical and the other (most probably) profit/business oriented is what adds to the complexity. It’s like trying to write a novel for both sci-fi geeks and C-suite executives.

What I was reminded of this week was that a User Story must tell the narrative about a particular user behaviour with the product. It is a story in three parts:

  1. Who the user is
  2. What they’re doing
  3. Why they’re doing it


I like that we conceptualize these artifacts as ‘stories’ since stories are usually associated with the ‘why’ behind human behaviour. Journalists seek out motivations behind the humans in their news items in order to make their story richer and more compelling.

That third part, the ‘why’, is important not only because it is the red string that allows both the tech-savvy developer and the business-minded executive to agree on a universal goal that the User Story is trying to achieve, but it also provides the reasoning as to why the user will behave in that particular way.

The ‘why’ is always written from the point of view of the user. The ‘why’ is never “to increase profits by 20% in the next quarter” or “to save on annual storage costs”.

The ‘why’ always focuses on serving the user.

The ‘why’ can also influence design decisions. Does this User Story have the purpose of entertaining a user or is it intended to make their life more convenient? This may be the difference between creating a simple button or having a dancing hippo pop up on your screen.

When we are in the early stages of building a product, we are focused on all the things that a user will be able to do with it. We go wild with our imaginations and that’s perfectly OK.

But with every user behaviour, we need to ask ‘why’. Why would the user want to do that? How does that behaviour impact their lives? How will this feature serve the user?

Once we start asking ‘why’, then we’ll create products with more impact. Because then, behind each user action lies a great story.

All Aboard the Runaway Blockchain Train

The ever-curious and innovative Business Analyst is always trained on the latest solutions and how these can solve business problems.

Given the controversial nature of Blockchain, many a business analyst is understandably perplexed by this runaway technology. This decade-old train has long left its cryptocurrency embarkation station and is now rounding the curve towards gaining mainstream acceptance. Now is the time for you to climb aboard this free-wheeling train and right its journey through your organization.

Initially, your inquisitive BA side will certainly lead you down: document, market, and vendor analysis tracks as you learn more about this somewhat mystical and often misunderstood technology. In a nutshell, blockchain is “a distributed and immutable record of digital events, which is shared peer to peer between networked database systems that utilize cryptographic and security technologies.” As part of your research, you will certainly grapple with such concepts as immutability, disintermediation, and cryptographic hashing.

But don’t get railroaded! At its core, blockchain is simply a distributed ledger system that securely processes transactions that are maintained for posterity. Picture a ledger as a living spreadsheet with each chronological transaction being added as row within a record’s tab. A group of digitally signed transactions form a block that is linked to a related, preceding block via a practice called cryptographic hashing. As a result, an immutable and uninterrupted blockchain of encrypted data is formed and made available to all within a disintermediating network – one without a central, intermediary system being in control.

As led by a conductor-less locomotive engine, this blockchain train faces the risk of becoming derailed at critical junctions that lack signals for direction. In the rush to the light at the end of the tunnel, corporations and government agencies are seeking to solve business problems via fast-tracked pilot and proofs of concept initiatives. To date, thousands of blockchain trials are barreling down unstable tracks that are not bolstered by technology standards, industry consensus, nor essential regulations.

As such, per the research and advisory Gartner organization, few if any blockchain deployments have reached a productionalized state within these sectors. Still, leading technologists advocate joining this captivating and bounding train as it ventures through all sorts of learning curves. Yet, don’t head down the same tracks as these energetic and well-meaning blockchain technologists who have eagerly trialed blockchain solutions. In so doing, many have employed the equivalent of a railroad tie hammer in search of a needed spike.

Instead, by leveraging your interface analysis skills, you will soon learn that blockchain nodes (e.g., servers, desktops) are akin to train stations distributed across the landscape. Depending on their roles, they are involved in transmitting, verifying, validating, and maintaining data within the decentralized network.

Further, the train’s jouncing cars are best compared to key blockchain design components – representing a set of technologies that are often misunderstood. Each technology is striving to right themselves towards maturity to support the stability of the blockchain:


  • Security Access: Utilizes identity access management practices to grant rights to only those nodes that are known and trusted.
  • Cryptography: Protects records by use of the above hash functionality, private keys serving as digital signatures, and encryption practices.
  • Provenance: Instills an audit trail, as achieved by the chaining of records.
  • Smart Contract: Incorporates business rules that are automatically run to verify a transaction’s correctness.
  • Consensus: Validates the formed blocks, per agreed-upon proofing algorithms, before committing to the ledger.

By training your focus on these nuts and bolts features, you can best rely on your change agent talents to promote interest in blockchain within your organization.

Befitting your cautious yet ambitious mindset, step back from this fervor and assess the value proposition that blockchain holds. Take a look at your current transaction-based networks (oftentimes structured with a centralized, controlling hub) and ask yourself:

  1. Is the quantity of interdependent, transaction-based records large, and does this volume require high-performance processing? (i.e., distributed ledger)
  2. Can data be equally shared in a network among a sizeable number of partners – rather than maintained by a centralized resource? (i.e., decentralization, consensus)
  3. Must data be limited to participants due to security or privacy reasons?
  4. Are extensive regulation-based and audit-related activities frequently performed to ensure correctness, immutability, and traceability? (i.e., engrained auditability)
  5. Does data require processing via complex or regulation-based rules? (i.e., smart contract)
  6. Is the current network vulnerable to fraud or cyber-attack? (i.e., cryptography)
  7. Are network participants willing to share data and the associated processing activities?

If you can answer “yes” to a majority of these questions, then proceed by identifying business use cases. Candidates that are gaining blockchain steam include: supply chain management, identify management, contract management, financial record reconciliation, records management, and case management.

Further, your creative mind will likely spark even more use cases to explore.

So, embrace your evolving blockchain evangelist role and pitch your well-thought-out recommendations to your leaders, teams, and even external partners. Enlighten them about blockchain’s potential to transform the way organizations do business and delight their customers.

Better to climb aboard now and get your organization’s gears going, then missing the train all together as it nears a destination of widespread, mainstream adoption next decade. And if you are ready to embark on this incredible journey or even pilot it, then it’s full steam ahead!

Secrets of the Cat Herder – Part I

How to be in control of the Development Team that your project depends upon

“Control your own destiny or someone else will.”
– Jack Welch

If you’ve spent any time as a Product Manager, Business Analyst or Product Owner, I’m certain that you have experienced frustration dealing with an Engineering team. I am here from “the other side” to help. I have spent the majority of my career on the technical side of software development, but also a significant portion in “business” roles such as Product Management. The purpose of this article is to let you in on the secrets I have learned from being on both sides; these secrets will help you assert control over your projects.

First, I should say that we1 don’t really mean to be frustrating – as a rule, we are trying to the best of our abilities to achieve what we believe to be the objective of our department. The problem is that we often have a different objective than you do. What is the Engineering team’s objective? Like the blind men and the elephant, you will almost certainly get different views on the topic from each Engineer.

As a business person, you might surmise that it is something like “spend a lot of time using cool new technologies to create a small amount of business functionality while staying gleefully unaware of business pressures”. Trust me, that’s not what any of us would write down.

Here’s the good news: the actual objective of Engineering is the exact same as what I assume yours to be: to efficiently (i.e., rapidly and cost-effectively) deliver valuable business functionality for Customers. How can I be so certain?

The essence of my analysis is based on the fact that the Engineering team must share the same objective as the overall company, which for most for-profit companies is to maximize profitability (although if the company is publicly-traded, it is more accurate to say “increase shareholder value”). To skip a few steps in the reasoning and cut to the chase, this is normally done by maximizing the valuable functionality delivered to the Customer; to restate for effect:

The primary purpose of Engineering is to efficiently create valuable functionality for Customers2.

Although they both might assume otherwise, you can see that the business people and the technical people share the same objective. So what’s the problem?3 The chief problem is that the Engineering team doesn’t know this yet.

Notice that the objective stated above doesn’t say anything about architecture, frameworks, languages, coding standards, testing approaches, etc. These are the things that Engineers love to focus their time on and things that the outside world assumes to be their primary objective. It’s not to say that these things are not important, but they are only important in so much as they help achieve the overall (and really, only) objective which is to provide value. A corollary of the above objective is the following:


The only Engineering activities that are worthwhile are those that lead to delivering value to the Customer.

I often talk about something I call the “Customer Membrane” – it’s the surface area where we exchange things with the Customer, such as the software we deliver, designs, requirements, feedback and usually some form of payment for the value that it is delivered. The Customer Membrane looks something like:

ricker 08242018aI propose that if something isn’t visible in the exchange at the Customer Membrane, then that “thing” is not particularly important. For example, if the team has decided to use an obscure programming language in the back-end of their cloud-based solution, this doesn’t matter to the Customer. So let me repeat this in bold print for emphasis:

The most important Engineering work is that which is obvious across the Customer Membrane.

You can use this fact to help keep the project team focused on those tasks that make a difference and not those that are really interesting to the Engineers, but not valuable to your Customer.

So how do you help the Engineers figure this out? I am a big believer that revolutions start in one of two ways – from the top down or from the bottom up. I suggest starting with the former since people at the top generally have the authority to start a revolution.4 Start by working with Engineering leadership to convey the above ideas (I will provide more supporting materials in the next article). Engineers are very logical and my experience is that when these ideas are explained clearly, it makes sense to them. At first, it goes against their natural instincts, but with repetition, the passage of time, some successes and the realization that they can still do great and interesting Engineering work, they will come around. I promise.

One of the most common objections to the message is that it prevents Engineering from doing “their thing”. Because they hear words like “value” and “functionality” and “Customers” and not a single technical term, they assume that there is no place for technology. One key thing that I’m not saying in this definition is this: “Engineering can no longer use new, interesting technologies and do challenging, innovative work.” Choosing to make the delivery of business functionality the primary focus does not prevent innovation and the application of cool technologies. However, it is very different than focusing first on picking shiny technologies and worrying later how they might be used to deliver on the business needs.5

Until Engineering leadership buys into the fact that their only objective is to efficiently deliver valuable functionality, it will be difficult for you to progress. Therefore, I encourage you to be persistent in delivering this message. If you can’t get support from the leadership, then go to Plan B, which is the grassroots Revolution. Try instead delivering the message only to the Engineering team working directly on your project. It’s a smaller group to sell the idea to and, if successful, they might be the wedge that helps you to convince the larger group. Either way, you need to do your best to get this message to percolating in the Engineering side of the company.

I’ll continue this discussion in my next article here, but in the meantime, I invite you to take a tour through my blog site at de-engineering – it covers the above concepts in more detail.

1 I normally self-identify as a techie.
2 Keeping in mind that the “Customer” can be an internal one.
3 Because there definitely is a problem!
4 Although you can’t authorize your way to a revolution, despite frequent attempts.
5 I suspect that many of you can identify with this type of environment. What you don’t realize as business people is that new technology is like catnip to us Engineers. When you don’t control the infusion of new technology, you create one of those crazy cat playgrounds where disorder rules supreme. The phrase “herding cats” did not get invented by accident (by the way, the original video that spawned the phrase can be seen here).

Using prototypes to write requirements

When I started out as a Business Analyst, I worked on many small projects that dealt with internal application development.

Requirement elicitation was easy as the requirements were precise and the user navigation steps were simple. I didn’t have to think much from the design and spacing perspectives as all the stakeholders, and end users were from within the organization, and as long as the purpose of the application was being served, the design of the application would take a backseat.

But as I progressed and took up bigger projects – projects that were creating revenue for the organization and that were being used globally – I realized that I had to be very careful in writing the functional requirements. I had to be aware of each and every functionality on that screen to make the requirements more effective. The user management had to be explained in detailed, and I had to keep in mind the design of the application and be more though with the navigation flow.

Initially, I used to take the visualization approach in writing the functional requirements – Imagine the flow in my head and keep writing. However, when I reviewed these requirements, I observed that I did miss out on some aspect or the other. Eventually, I had to add more details to complete the requirements.

I then began to use prototypes to write the functional requirements. Remember how back in school we were told to use paper for rough work to do our mathematics calculations. In the same way, using prototypes to solidify the navigation flow can be a good approach.

As per many, a prototype or a mock-up is defined as the blueprint of screens or a visual guide that represents the skeletal framework of a website. A better version of a mock-up is a wireframe. Wireframes take into account the complete design aspect of the software. Mock-ups are rough drafts created in the beginning to put the elements of a website in place.

Take this for instance – you are required to spearhead a project in which an application has to be developed with which end users can buy fashion accessories. Some of the initial questions you may ask the stakeholders would be about:

  • Customer base
  • User journey
  • How will the payments be processed? The payment gateway integrations
  • If user can make a purchase as a guest user
  • Where will the user apply the promo codes?
  • Which filters can be used by a user?
  • Are we maintaining any order history?

The answers to these questions will help in drafting the high-level requirements. But what about the following questions?

  • What all can a user do in his / her account? – Change profile
  • How will the navigation between pages be? This may seem simple, but the stakeholders may have a different opinion. For example, you may think that when a user is on the review order page, and when the user clicks on continue shopping, s/he should land on the product listing page. But the stakeholders have a different requirement – They want the user to land on the home page of the website. BAM there’s a gap now!


Case – Requirements without a prototype

Let’s say you are to capture requirements for the order history page in the user’s account. You imagine the page in your head. You first write about the basics – The page will have the following details:

  • Order No
  • Product details
  • Total amount
  • Promo Code discount
  • Amount paid
  • Status

Case – Requirements with a prototype

Now, what about the details at the granular level. You make a mock-up with the information above and analyze the order history page further.

mehta 03012018

  • Can the user click on the product details and view the different products in list form? If yes, then can the user select each product to view its detailed page?
  • Can the user view the amount breakup and the mode of payment?
  • Will the status be a pictorial representation or just a text?
  • Where will the images of the products be placed?
  • Given the layout above, how will the space to the right be utilized? If the stakeholders request to add some banners how that will be done?
  • Does the return and exchange of a product happen on this page?

This is just a small module. When it comes to the entire application, the complexity may increase, and the requirements may have to write in much detail.

Mock-ups are the binding agents of the requirements. They help in understanding the user journey which can eventually help in effectively drafting the use cases. These are easy to make and are effective in identifying gaps. While various tools are available in the market, mock ups can be done in the basic pen paper mode too. One doesn’t need to be adept with the design aspect. However, a BA should consider each aspect of a screen and make sure if there’s a requirement associated with it. The main purpose of a mock-up is to have a complete picture of the user journey. Moreover, the feasibility of the features can also be assessed.

Having a mock-up for reference can be helpful in the following ways:

  • Functional requirements can be written in a modular way. As mock-ups deal with all the screens of the software, one can map the navigation amongst these pages and write details about the user journey.
  • It helps in filling up the requirement analysis gap. For example, during requirement elicitation, the stakeholders may skip a feature. However, if a rough structure is in place in these sessions, the chances of missing a detail are minimal.
  • One doesn’t miss out on a user story. For example, the order history is in place but as a user, can I sort/filter the records? If I click on an order, can I see the detailed page of a product purchased?
  • Requirements when coupled with mock-ups give a clearer idea to the developer who can consequently code with confidence.

Are You Suffering from Agile Fever?

Have you ever come across a colleague or a family member who has a knack for making every conversation about them?

Do you have people in your social circle who influence every group decision to their benefit? Of course you do! When describing these people we typically say “You know the whole world revolves around Joe!” Do we really enjoy spending time with these people? Of course we don’t because they are exhausting and frustrating to work with. Well let me tell you something, these people have a lot in common with user stories. The user story has become the center of the Agile world. Everything in Agile seems to revolve around the user story. They have become exhausting and frustrating to work with for many of us. How did we allow this to happen? How did the Agile community get to choose the technique we must use to convey the requirements for a solution? The BABOK details numerous techniques that BA’s can master for the purpose of eliciting business needs, determining “wants” from true “needs” and communicating the actual requirements which must be met. Why is the user story being elevated in importance over all other techniques? I have personal experience in “Agile” organizations who are absolutely obsessed with the user story. I’ve also been fortunate enough to meet many of my BA colleagues at conferences who have the same frustration. Why do we seem to be limiting ourselves or over relying on this one technique?

Mike Cohn of Mountain Goat Software is regularly credited with coming up with the format of a user story. I’m sure we’re all familiar by now with the “As a _____, I want to _____ so that I can _____.” format. By no means do I intend to discredit this format or this technique. It can be valuable in the right situation.

However I view the user story as a singular tool within our BA tool belt. One single tool should not be the center of any development methodology. Unfortunately I’ve come across some development colleagues who are infected with Agile fever. Agile fever causes the temporary loss of common sense and logic and is characterized by an irresistible desire to adhere to an irrationally dogmatic process. Those infected with Agile fever latched onto the user story as the center of their world since it seemed to have lots of potential. It has a simple format and it seems that anyone can write them. With the user story as the center of the universe time consuming business analysis could be eliminated and replaced with simple user stories and conversation! What a eureka moment this must have been in the Agile community. I can imagine the crazy celebrations which must have ensued. As many of us are learning this is not necessarily working out as planned. Some organizations that tried to eliminate BA’s or relied entirely on the conversation generated from user stories learned that Agile fever can have serious consequences to their business.


So what does Agile fever look like and how can you tell if your team may be infected? Let me give you some examples. A developer once explained to me that he understood the requirements and knew exactly what we were doing and why. However he demanded that the requirements be reworded into the typical user story format because our group was “Agile”. Agile fever was infecting him to the point that he could not function unless the user story became the center of his world. Once the requirements were rewritten he instantly calmed down and was able to function once again! If project team members are demanding requirement rework so you can be “Agile” then you’re likely infected. Agile fever can also cause Goldilocks paralysis. If you’re not familiar with Goldilocks it is the story about a little girl who wanders into a home occupied by three bears. While in the house she tries out three chairs exclaiming “This chair is too big! This chair is too small! And this chair is just right!” I must warn you that Goldilocks paralysis is extremely contagious and can infect entire project teams very quickly. It is characterized by project teams that spend significant time arguing over the size of the user story. You’ll hear comments such as “That story is too big! That story is too small! “We need to break these stories down” or “This story doesn’t fit in our sprint”. As a BA if you notice teams arguing over the size of a story and wasting significant time over it then be aware that they are infected with Goldilocks paralysis. It is treatable with an injection of common sense and reason but it may take a while to take effect depending on how high their Agile fever is.

So what do I suggest we do as BA’s to counteract this over reliance on the user story? I propose that we remember that the word “analysis” is in our job title. Therefore we must never forget that great analysis is what our methodology should revolve around not a single technique. Don’t let anyone influence you away from using other techniques. Great BA’s utilize the right tool or the right technique at the right time to uncover the business needs that will drive business value. The user story is one way to convey that information but it does not need to strictly adhere to the standard format. I have successfully used fully dressed use cases (Oh my!) on a project since they happened to be the best way to convey the requirements for that particular project. Don’t be afraid to think differently and convey the requirements in what may seem to be an unconventional way because it doesn’t fit into the Agile prescription. Drawing a picture, creating a wireframe or using some other visual technique will drive conversation much better than a standard user story. Do some stakeholder analysis to make sure all possible stakeholders are being considered. Then go ask those stakeholders to tell you stories related to the problem that must be solved. Trust me you will have richer conversations and uncover information that the traditional user story would not. My fundamental point is that we as BA’s are software professionals that have creative analytical skills that must not be suppressed by an over reliance on any one technique. So wash your hands, clean your keyboards and get enough sleep so you can avoid Agile fever. If the BA becomes infected then the project team is certainly doomed!