Skip to main content

Tag: Use Cases

Writing User Stories When There’s No User

Written by Larry Blankenship on . Posted in Articles.

One of the first things most of us learn when we make the transition to Agile business analysis is how to write user stories.

If you’ve started your Agile journey, you’re probably familiar with the format: “As a , I want to so that I can ”
However, what happens if you don’t have a user, but instead are dealing with a system? When I started working in Agile, I didn’t have users to write user stories for, I had APIs and file transfers. The users in my case were the systems that would consume the output from other processes and create output used by other processes. 
I had to come up with a different way of thinking about user stories. The user isn’t directly involved in the process, or was involved so early in the process, that they don’t have much input or effect on it. I found it was hard to identify roles or user profiles to include in the usual format. This article is about how I learned to work differently to address that question.
When there isn’t a user, the purpose or value of the story has to become the focus. The system should always act the same given the same inputs, so there isn’t the kind of variation you would see with a human user. What becomes more important is the reason the story exists at all: the reason for the system to behave a certain way. Granted, the value of the story is important whether or not a human user is present, but it becomes more important in this case.
In my world, most of the requirements come from changes in state law or legislation, so the reason for a story is quite often to comply with regulations, or to provide required information to the state. In other cases, the department that handles reporting and inquiries from the state needs information to be processed in a certain way, but still doesn’t have direct interaction with the systems that do the processing.
Advertisement
In order to deal with this problem, I use a couple of different formats to write my user stories when a user is not the subject of the story: “In order to/for , the system .” I try to include the business unit or entity that has the objective in the first clause, as it makes the value of the story clearer.
So for example, I might write “In order for the state to process vehicle records properly and to provide efficient transmission, the system sends a valid driver’s license number with each record.” In this instance, the value of the story is that the state is able to process vehicle records properly. If I wanted to, I could go into more detail about that, but since all of the people in my team know why this is valuable, it’s not required. 
I can, and often do, provide details about the objective not being achieved as part of the story discussion or as part of the acceptance criteria. This story would probably be part of a larger epic describing what a valid record means for that state, listing all of the fields that need to be validated before a record can be sent. I might include the detail about the consequences of invalid records being sent at that level, since it applies to all of the data in the record. This story is one part of that epic, but keeps the focus on just one data element. I like doing things like this as epics because it’s easier in a case like that to combine stories or separate them to to organize the work.
Another way to write these, if you prefer, is to say “Because , the system . Again, I try to include who made the requirement necessary in the initial clause to make things very clear as to why the story is valuable.
After I discussed this with some of my fellow BA types, one said, why not make the system the user so you can use the usual format? For example “As a , I need to , so I can . This is a perfectly acceptable way of doing things. I do think it takes the emphasis away from the value of the story, which is why I prefer the first two formats, myself.
Once we’ve written the user story, most of us know that the next step is to write acceptance criteria and provide other information that the developers might need to implement the story. In this case, I would need to provide rules for identifying a valid driver’s license number for the state in question. I would also need to provide a set of acceptance criteria to give the developer a way of knowing when the story was complete. 
Most of the time this is in the form of use cases or a list of business rules that describe the incoming data, and what gets done about it in terms of error messages, logging, or other responses to the data. This might actually create an ancillary user story involving a human user, for example “As a state reporting specialist, I need to receive an email when a record is rejected by the state.”
Writing user stories is an essential skill for Agile business analysts. Focusing on value is one way to address “userless” user stories. While value is always important, it becomes especially critical when user behavior is predictable and definable.

Design Thinking for a Business Analyst

Written by Rovena Bytyci on . Posted in Articles. 1 Comment on Design Thinking for a Business Analyst

Design thinking is a concept that was first introduced back in the 1960s and has recently gained a lot of traction in the business world.

Adopted by many high-profile FTSE 500 companies such as IBM, Apple and Google to increase innovation and improve products and services, design thinking is becoming a part of everyday operations in organisations across the board.

What is design thinking?

Design thinking refers to the ‘cognitive, strategic and practical processes by which design concepts (proposals for new products, buildings, machines, etc.) are developed by designers and/or design teams. Many of the key concepts and aspects of design thinking have been identified through studies, across different design domains, of design cognition and design activity in both laboratory and natural contexts.’
Essentially design thinking revolves around gaining a deep understanding of the people that a product or design is being created for. It is widely accepted that there are five different phases of design thinking in no particular order;

  • Empathise with your users
  • Define users needs, desires, problems and your insights
  • Ideate by challenging common assumptions and creating innovative solutions
  • Prototype and start creating effective solutions
  • Test your solutions
Advertisement

What does this mean for BAs?

The very nature of a business analyst role is analytical, and this is unlikely to change, especially in an era of rapid digital transformation. However, this doesn’t mean that certain concepts of design thinking can’t be applied in practice to the role of a Business Analyst. Design thinking is in essence just another form of business analysis and many BAs will have used design thinking concepts in projects before. Perhaps the most common areas that business analysts can apply design thinking are scope definition, requirements elicitation and analysis and validation of decisions. The depth and length of the process will largely be depending on the scale and complexity of individual projects, and as organisations are becoming increasingly agile, so to will the concepts that business analysts are required to use.

Embracing design thinking

For business analysts embracing design thinking can allow them to become more analytical, user-centric and effective. By applying the skills and techniques developed as a BA and undertaking further education, this can also accelerate growth and career trajectory. Approaching a project with a purely business or analytical mindset will no longer be enough – for a Business Analyst, this could mean developing elicitation techniques, rhetoric skills, facilitation, and influence for a more effective project outcome.

The Story Behind User Stories

Written by Lucy Munanto on . Posted in Articles.

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
Advertisement

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

Written by Thomas Burke on . Posted in Articles. 1 Comment on 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:

Advertisement
  • 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

Written by Darryl Ricker on . Posted in Articles.

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:

Advertisement

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.

Footnotes
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).