Skip to main content

Tag: Elicitation

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

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.

Why Bother With Current State?

Recently I found myself walking some senior managers through a requirements document I had prepared when one surprised me with a question I did not expect.

They wanted to know why there was so much of the document devoted to describing the current state and the various challenges and deficiencies the organization faces in the relevant process. It’s a fair question, but after a decade of business analyst work, I had started to take the importance of detailed current state documentation for granted.

So why bother with current state?

For one, current state documentation is how we demonstrate to our stakeholders that we’ve been paying attention and that we understand what they’ve been telling us. This helps to build relationships with stakeholders, but more importantly, it keeps us honest. It’s an opportunity for our stakeholders to audit our knowledge of their challenges. If we aren’t working from an accurate understanding of what the problems actually are, what are the odds that our requirements will drive us towards a solution that addresses the underlying issues rather than a symptom? I always challenge the business analysts that report to me to explain the problem before they start talking to me about their requirements for precisely this reason.

It’s also necessary background for our solution providers. Let’s envision two distinct scenarios.

If we’re working with software developers to implement a change request or enhancement to an enterprise system and we give them a laundry list of “the solution must” statements, the few that can stay awake all the way through a requirements review are not going to be able to provide any special insight.

They may still develop a fully compliant solution, and if your requirements are darn near perfect, you might even deliver a solution that passes user acceptance testing on the first try. But I wouldn’t be optimistic.

Imagine instead a requirements review meeting that begins with a detailed explanation of what a day in the life looks like for the person we’re developing this solution for, where we focus on the challenges this enhancement or change is meant to address. Then we start talking about the functional requirements, and our developers are engaged and using their own reasoning and logic to see how these requirements relate back to the problem.


Advertisement

It’s been my consistent experience that the vast majority of software developers find this to be far more exciting, and that only makes life easier for everyone. This is especially valuable if you’re working with folks on an internal team that you’re going to continue to work with again and again on future projects. I think you’ll find this often leads to some great suggestions that you wouldn’t otherwise benefit from, too.

Alternatively, if we’re going to be bringing in consultants to assist in selection or implementation, whether hardware or software, the need for current state documentation is even greater.

Without detailed current state documentation, how are we going to bring the outsiders up to speed? It’s faster and more accurate to work from a well written, edited piece of documentation that already contains all of the relevant and applicable flow charts rather than trying to explain the background as you walk through the requirements. It’s especially nice if you can provide the documentation in advance and they can come in with the gears turning and their questions ready on Monday morning.

When we’re working with external solutions providers, we also may not have the opportunity to “fix it in testing” (not that should we be relying on that). This is especially true if we’re selecting or implementing hardware solutions.

For example, you might provide a great set of requirements that allows the vendor to suggest a wonderful touchscreen computer… that you then go to implement in a manufacturing environment where the employees must wear protective gloves that render the touchscreens inoperable. If only you had explained who was going to be using the computers and what for, the vendor might have known from experience to ask the right questions and may have suggested alternatives or at least provided you with the foreknowledge to order compatible gloves.

It also always takes longer to re-explain misinterpreted requirements than it does to start off by explaining what’s happening in the first place. No matter how great your requirements are, they’re always going to be subject to interpretation, and nothing helps to ensure the intended reading better than a shared understanding going in. This is true regardless of who you’re working with to arrive at a solution, but if you’re working with external consultants or developers, it becomes that much more expensive to spend time going back-and-forth. Later on when it’s time to explain why the project ran over budget, it’s going to be bewildering to a stakeholder who is familiar with the current state as to what was so confusing about the requirements. This reflects poorly on all involved, and unnecessarily so.

So, why bother with current state? Because it will help you get to a better solution, with less effort, less re-work, less expense, and provide an all-around better experience for everyone from the stakeholders to the solution providers.

Well-defined Data Part 4 – Products Customers Sales and Locations

This article discusses entities supporting the concepts product, customer, sale, and location.

The names given to these entities varies depending on the line(s) of business an organization is in and, in particular, the organization’s sales processes.

Product-Related Entities

The concept of product within the context of this series was defined in Part 3 as covering both goods and services, where ‘goods’ are things a customer can take ownership of and ‘services’ are resources a customer uses for a period of time. Goods have inventory levels (i.e. one or more instances available for purchase). Services have resource availability, at designated times (i.e. trained or qualified individuals to perform the service, and/or equipment appropriate to fulfil the service).

An entity representing an organization’s products will do so as a type, a batch, or as an instance.

Product Type – The products offered for sale by many organizations are not unique. For example, clothes, furniture, electronics, and pre-packaged food found in retail stores. A product type entity is used to record the name, size, price, etc., where values for these attributes apply to all instances of a given product.

Product Batch
– Products that are mass-produced can have one or more things vary within their production process (e.g. involve batches of components or ingredients from different suppliers). When it’s critical to an organization to track these variations, a product batch entity is needed. Its purpose is to maintain details about critical variable elements. Each product instance produced as part of that batch is associated with its batch instance.

Product Instance
– Some goods products are, by their nature, unique. Examples include property (i.e. real estate) and works of art. Other goods start life as similar, mass-produced instances, but can take on individual characteristics over time as the result of normal use, instance-specific modifications, or damage.

When an organization sells used, modified, or damaged goods, an entity representing each product instance is needed. That entity may make reference to the instance’s product type, if available, to represent its time-independent attributes. The product instance entity will need attributes similar to those of the product type entity, where a value that was common when the product was new can change over time. Plus additional attributes will be needed in the product instance entity to classify and describe its current condition.

In the case of service products, a product instance entity is not for the purpose of representing changes over time. Its objective is to represent specific ‘offerings’ of the service. Examples include appointment time-slots, rental availability periods, a specific scheduled flight on a route, the designated time and venue for the screening of a film, a live performance, or sporting event.

Well-defined data about products involves recognizing which of the above levels are needed by the organization, and naming those entities appropriately. When multiple levels are involved, product details (attributes and relationships) are included at the appropriate level, including the linking between levels.

Customer-Related Entities

An organization supports processes to maintain details about its customers within an IT-based system for one or both of the following reasons:

  1. The organization has an ongoing relationship with, or obligation to, its customers in relation to the sale of one or more of its products (e.g. supply of electricity, a loan, an insurance policy).
  2. The organization wants to be able to communicate with its customers to sell them additional products (e.g. the newest generation of a consumer product, a one-off service that a customer can benefit from periodically).

There are many organizations, such as those involved in retail sales, which sell their products to unknown customers. One mechanism commonly used by organizations to know who their customers are is a customer loyalty scheme. The customer provides their name and contact details in exchange for discounts or other forms of rewards. Another mechanism is warranty registration, where a manufacturer records the end-consumer of its products, even though the product was not sold directly to that individual.

Some organizations offer some or all of their products only to qualified customers. Banks only provide loans to credit-worthy customers, but offer savings accounts to any customer. Some educational organizations want only the ‘best possible’ students to fill their limited student numbers. Training organizations that have more availability than students will typically accept anyone that applies. Certain healthcare procedures may require a patient to be in an appropriate state of fitness. Specific government services may only be provided to persons of a given status.

Depending on the products an organization offers, and its sales processes, the types of customers it maintains in its IT-based system may be one or more of the following:

An Individual — a person able to provide enough information that they can be distinguished from other individuals within the IT-based system. E.g. name, address, phone number, government-issued ID number.

Multiple Individuals
— two or more people who are jointly involved in the sale of a product. E.g. a joint bank account, a family mobile phone plan.

An Association
– a named group of individuals associated through a common factor (e.g. a profession, sport, or hobby). The association itself may be the customer, or individuals members of the association.

A Registered Business
— an individual or organization that has officially registered to operate as a legally entity. E.g. a sole trader, a corporation.

A Reseller
– an individual or organization involved in the sale of an organization’s products, either with the intent of reselling the products to their own customers, distributing the products further down a supply chain, or acting on behalf of individuals or organizations (e.g. a travel agent). A reseller may be franchised to use the branding of the organization.

A Governmental Branch or Department
— an organization unit within a governing body with authority to procure goods or services from external sources. E.g. The Army, The Department of Education, a state-owned enterprise.

A Registered Internet User
— a person that has established a unique logon ID with an organization’s internet site. The organization operating the site may or may not have a business process that associates the user to an existing customer. In cases where it does, the user is not an additional customer, but an individual with access to one or more self-service capabilities on behalf of that customer.

Well-defined data about customers recognizes the line-of-business-specific name the organization uses to reference them, such as Client, Agent, Patient, or Resident. Attributes maintained for customers include name, contact details, and information applicable to repeatable sales events (e.g. account balance, available credit, medical history).


Advertisement

Sale-Related Entities

The concept of sale within the context of this series was defined in Part 3 as any type of event where a customer commits to consuming one or more of the organization’s products. Depending on the product(s) involved, and the organization’s end-to-end sale process, there may be pre or post-sale event events triggering activities within the end-to-end process. These activities can involve additional sale-related entities.

Pre-Sale — A pre-sale process may be triggered by a customer or the organization. Where a customer is seeking a product offered by a particular organization, the customer triggers the process. Examples of pre-sale activities within the sales process include the customer filling out an application or order that identifies the desired product(s), or requesting an appointment, quote, or reservation.

Where the organization proactively seeks a sale by contacting a customer, each contact event is supported by an activity that can result in an offer being made to the customer.

Having initiated a pre-sale process, there can be additional events and their associated activities that take place prior to formal commitment to the sale. Examples include the customer making a refundable deposit, the organization providing a quote, submitting a bid, drafting a statement of work, or the customer and organization negotiating a contract.

Sale Commitment — Within an organization’s sale process there will be at least one activity representing the customer and/or the organization formally committing to the sale. The customer can be said to place an order, sign a contract, or pay for a booking.

Post-Sale Events
— Lastly, there may be post-sale events related to the product sold, that trigger activities within the end-to-end sale processes, and involving post-sale-related entities. From the customer side these may involve subsequent purchases or usage of the product within the terms of a contract, either incurring an additional charge or utilizing pre-paid credit. Or the return of a rented item.

From the organization side, a post-sale event may involve charging a periodic service fee. Or a product may be delivered subsequent to the sale (e.g. the operation of a scheduled flight or an entertainment event taking place that was ticketed in advance). Payment may be due, or overdue for a product that was sold on credit. A service may involve periodic reporting, such as the production of a statement of account.

Well-defined data about a sale includes all entities involved in the end-to-end sales process, naming them in accordance with the line of business and organizational terminology. Attributes maintained for these entities can include the event-related dates, quantities of usage, and amounts charged to or paid by the customer.

Location-Related Entities

The concept of location within the context of this series was defined in Part 3 as a place managed by the organization for the purpose of the selling or the consuming of its products. Examples include retail stores, hotels, library branches, and properties provisioned for usage of utility services such as water or electricity.

As with products, customers, and sales, the organization’s location types relate to a given line of business. Locations have a positional aspect and an operational aspect.

The position of an organization’s locations can be:

Area-based — one or more named geopolitically-defined areas (e.g. suburbs, cities, states/provinces, countries), or map-drawn and named by the organization (e.g. sales districts, service coverage areas).

Line-based
— Two or more named points defining start, end, and any intermediate stopping points. E.g. passenger air, rail or bus routes, goods transportation routes.

Point-based
— A place identifiable by address and/or map-based reference. This includes locations the organization provisions with sales-related staff, such as a retail store, hotel, or bank branch. It also includes residential and commercial properties the organization has provisioned with network-based access to its product (e.g. water, gas, fibre).

Sub-Location
— An identifiable point or area within a larger location. E.g. a designated floor within a building, section or seat within a sports/entertainment venue, a specific storage location within a warehouse.

Where goods are involved, an organization cares about its locations from both an operational and inventory perspective. Operational in the sense of business hours and sales staff on hand during those hours.

Where services are involved there is additional need for service-appropriate resources to support advanced or ‘walk-in’ sales. E.g. flight crew, medical staff, a rental vehicle, an aircraft or ship to provide seating or cargo space.

Well-defined data about locations involves line-of-business-specific entity names. Attributes within those entities are needed to represent its position, operation, inventory and other required resources.

NOTE: Depending on organizational context, a location can be an area or a point. E.g. from the perspective of a city authority, the city is a bounded area, but from the perspective of an airline it is a point.

Click here for Part 5 — A Business Entity Identifier Attribute

Are you struggling to elicit requirements from your Stakeholders?

Gathering requirements from business stakeholders on your project is often very demanding and sometimes uneventful.

There are a number of ways to drive the conversations to ensure the requirements are captured and turned into meaningful detailed requirements.

This article suggests some tips to nurture the most out of the project team during requirements gathering.

Ensure you have buy-in from the project team

The team has been selected by their managers to participate in the project. They are the ones with the subject matter expertise. These team members must have the right attitude for the project and understand what it means to workshop requirements. Projects team members must be 100 % committed to the project and understand the project outcome.

Ensure the team understand why requirements gathering is important

Inform the team how important this part of the project stage is. If the scoping process and fleshing out of the requirements is not carried out correctly and efficiently prior to the development stage, then later on the team will be left with a long list of clarifications and a long list of issues during the testing stage.

Prior to the workshops

It is always good practice to discuss the approach you will take for the requirements gathering sessions. This needs to take place before the workshops. It is a good idea to have a brief meeting on the approach that will be used. The meeting will also cover any questions that people may have including ensuring they understand what activities they will be performing.

If this approach meeting is held first, then the team can dive straight into requirements workshops. Remember, everyone’s time is precious.


Advertisement

What kind of workshops?

Always have the problem statement close at hand. That way everyone can keep referring back to it during the workshops.

User stories form a good basis that can be developed and fleshed out during the workshops. Requirements that are captured using user stories tend to capture three key items: Who the user is; what the user needs; why the user wants it.

Use these stories and keep referring back to them while developing your requirements.

Processes

Business processes are key assets to the project. The current processes in both diagram and steps formats are one of the main essentials for capturing and developing requirements. They describe how things are done and provide insight on how things could be improved on and how they are done.

Mapping out future state processes may take several workshops however once a couple of processes are near complete the team will understand why these are so important.

Summary

The three key items to successfully elicit requirements from the Stakeholders:

Engage > Question > Confirm

What BAs Do to Remove Bias in Machine Learning

Do machines make better decisions than people? This is a question every BA should be pondering and debating.

Machine learning and other artificial intelligence capabilities are expanding to every industry. Machines are analyzing data to write news articles, predict when car parts will fail, identify customer emotions, detect credit card fraud, drive cars, diagnose cancer and identify criminal behavior.

What are the consequences of bad decision making in these areas? Biased data could prompt machines to make decisions with consequences ranging from fake news and irrelevant advertisements to false arrests and even death.

Many companies are wasting millions of dollars developing innovative products that fail to meet expectations. A few companies are getting it right and thriving. What’s the difference? Well defined outcomes and good analysis!

But it’s not traditional analysis. With machine learning, the machine learns the decision logic on its own through patterns and does not have to be explicitly programmed with a logical specification of requirements. The machine, not the BA, uses data to identify business rules and many requirements. Does this mean BAs are obsolete? Absolutely not! BA skills are even more important when we are relying on machines to make decisions. Why?

Because machines still don’t make good decisions without people

People play a different role in machine learning! BAs working on machine learning projects shift their efforts from traditional requirements elicitation and analysis to have more focus on experiments and solution evaluation.

Solution evaluation is about looking at a constructed solution, machine learning algorithm perhaps, and how it is serving user and business needs. The solution doesn’t have to be fully built to be evaluated—a prototype or minimum viable product is great starting point.

Here’s what the solution evaluation cycle looks like:

wick 07302018a

Define Desired Outcomes

Many machine learning solutions fail because teams focus solely on technology and ignore the context, purpose and desired outcomes. At the beginning of any new project ,this is a key step for BAs. In the case of machine learning BAs will define (and continuously refine) desired outcomes based on understanding four factors:

  • The users/humans who are the source the data the machine is using
  • The empathy state of the user and their processes and workflows
  • The potential biases of user group and the source data
  • How to analyze the machine’s output and clean up the data to remove bias that creates practical and ethical issues

Advertisement

Understand Data

We’ve all heard of GIGO, right? Garbage in, garbage out. That’s especially true for the data used by systems that make automated decisions. If one data point is wrong, missing or misinterpreted, the organization and the user will suffer consequences.

It’s the BAs role to understand the data and continuously evaluate the data set. BAs help the team gain confidence that the machine has the right data to solve the problem and move the outcome in the right direction. BAs need to know:

  • Where the data is coming from
  • How the data is influencing the decisions made by the machine
  • Which pieces of data are meaningful to achieve the desired outcomes

Let the Machine Learn

One pitfall for teams is spending most of their time and energy defining, building and analyzing this part of the process. They get so focused on the actual machine learning technology that they miss out on the importance of learning iteratively through experimentation and analysis.

This leads teams down a path of self-destruction as teams fails to make connections between the technology, the data, the customers and the desired outcomes.

Experiment and Analyze

Successful machine learning solutions require multiple cycles of experiments and analysis. This effort gives us insights into what needs to be fixed. These insights are much more meaningful than reacting to a list of user requests. BAs use these insights to change the data, refine the questions and the modify the variables to discover the impact on how the machine learns.

But BAs do not do this by themselves in their cube! Instead, it’s a collaborative effort that includes the customer or at least a customer-centered approach. To help the machine make good decisions, BAs use experimentation and analysis to:

  • Observe what is and isn’t working for the users/customers
  • Analyze the business and user metrics that matter to outcomes
  • Analyze the user experience, customer experience, data flows and processes to determine how the overall process and solution is performing
  • Analyze real-time data to see how users are interacting with the solution
  • Identify any data that is introducing bias into the machine’s decisions

Remove Bias

After teams experiment and analyze, it’s time to refine the desired outcomes and update the data as needed to achieve the outcomes. A big part of that process calls BAs to remove biases identified in the machine learning results.

The team manages biased data in several ways. They can:

  • Remove biased data
  • Retrain the machine to handle bias data differently
  • Adjust the input process of users to remove/address the bias data

Teams that skip or minimize experimentation and analysis waste millions of dollars on projects that fail. Help your machines make better decisions by advocating for the importance of customer interaction, context, data quality, outcomes and refining the data based on experiments.

Machine decisions should make sense for our customers and our organization. And that requires a human (BA) touch!