Skip to main content

Tag: User Stories

Beyond Jargon: Bridging the Gap Between Precision and Clarity

A while back, I was taking a flight from London City airport. It’s an airport I don’t fly from very often, and I was looking for a place to fill my water bottle. Unlike other airports, I couldn’t find a water fountain anywhere. The airport staff all seemed busy, so I did what any good BA would do, I took to Twitter (or is it X?) to ask the airport social media team where I could get some water.

I got a reply really quickly, with the social media team letting me know that I could get water from any food concession in the airport. So, I went to one of the food shops to grab some sandwiches and got them to refill my bottle at the same time. Problem solved.

However, another Twitter user pointed out at the time that it’s a little odd they used the term food concession and not food shops or food stalls.  I mean, what even is a concession? A little bit of digging uncovers this definition:


“A retail concession is a dedicated space within a single-brand store that is used by a non-related but complementary brand. Retail concessions are essentially shops within a shop…“ (Quote from Unibox site)

So here, the airport is technically correct. The food shops are technically concessions, they are ‘shops within a shop’, or in this case ‘shops within an airport’ (let’s face it, airports feel like one big shop these days!).

But who, outside retail, regularly uses the term ‘concession’? And in the context of my query, does it really matter that it’s technically a ‘concession’ and not a ‘shop’?


A Balance of Precision and Understandability

As it happens, I did understand what was meant, so this wasn’t an issue. But I wonder if a tourist who has a basic grasp of English would understand (this was an airport after all). It strikes me that with communication there’s a balance of precision and understandability.

Some terms will communicate things very precisely, but only to those who are within a domain. My career started in insurance: words like “cover”, “peril”, “loss’, “policyholder”, “insurable interest” have very specific meanings. Those things are important within the insurance company… but outside most people just want to “insure their car” or “protect their house”.  Of course, for all sorts of legal and regulatory reasons, there needs to be precise and formal T&Cs and policy wordings. But the way that the organization communicates needs to be in a way that’s understandable.




Does Your Internal Lingo Accidentally ‘Trickle’ To The Outside?

This is an area where BAs can help. Often, Subject Matter Experts (SMEs) will be defining the text that needs to appear on websites, letters, emails and so forth. SMEs are usually fantastic stakeholders with so much knowledge. They are great to have on board!

Yet, the challenge of having so much knowledge is they might forget what it’s like not to know so much. An SME who has worked in insurance for 30 years might not easily remember what it’s like to buy your first insurance policy. Yet, it’s likely that the solutions we define (and the communications that go out) will need to be understandable to someone completely new to insurance too.

Highlighting where internal lingo has inadvertently trickled to the outside world can be useful. Asking questions like “would an average customer understand this phrase?” or “what about someone who has never bought our products before, would they know what this means?” can help. Having a set of personas can be even more helpful.


Prototype, Test and Learn

Another stage that is often missed when defining and designing websites, emails, letters and other forms of interactions with customers is to take the time to test and learn. Showing a customer a rough prototype with the wording and seeing how they react would be a great way of getting an early steer. Prototyping a letter that is going to be sent to 150,000 subscribers and getting input from 100 might help uncover misunderstandings or ambiguities. This might save thousands of confused calls to the call center, and thousands of quizzical emails.

In summary, communication is always a balance of precision and understandability. Knowing the audience, testing and learning helps avoid miscommunication and misunderstanding. BAs are well-placed to foster these types of activities.

Learning to Love Compliance

OK, I’m going to let you into a secret here. I genuinely like compliance projects. You know the ones, those projects that people think are really boring because they relate to a change in regulation or legislation? The ones that it’s really hard to get people excited about? The ones that few BAs volunteer for? Yep, those ones!


Framed differently, there’s often a real opportunity to shape and scope things in a way that isn’t always the case with other (seemingly more exciting) projects. These projects can be career-enhancing, provide more autonomy and really don’t have to be boring. Or, at the very least, they don’t have to be as boring as they first appear! Let me explain…


Pain Reliever or Vitamin

I remember reading somewhere that one question that some Silicon Valley venture capitalists will ask startups when they are pitching for funding is:

“Is your product a pain reliever or a vitamin?”


You might think it is better to be a vitamin. Yet, apparently, the answer that investors are looking for is ‘pain killer’. Sure, we might take vitamins some days, but it’s easy to forget. But if you’re in pain, you will soon remember to reach for the pain reliever. So, solving a pain point will likely get people to reach into their wallet.

Think about a change in regulation or legislation. Most people who are part of the core business know they need to comply, but if we’re brutally honest, they probably aren’t that interested. A change in (say) data protection legislation is just a distraction to them. They probably don’t care how it’s solved, as long as it doesn’t disrupt them too much, and as long as it doesn’t cost too much.  In fact, they might even be worried that the legal & compliance team are going to be ‘heavy handed’ and create all sorts of bureaucracy for them.


This is an area where BAs can act as a real pain reliever. By working with the relevant business areas and the legal and compliance team, by working with stakeholders to understand enough about the business operations, the solution landscape and the legislation or regulation we can co-create innovative solutions. We can find a balance that works for the different stakeholders, and rather than just achieving compliance, might actually improve things for them too. Imagine that, a compliance project actually leading to improvements!  It is totally possible.

Crucially, we take away a distraction for them. We get far more autonomy and leeway to shape things precisely because they just want the pain to go away.




Understanding The Problem

One of the things I love about compliance problems is the fact that business people usually haven’t pre-determined a solution. Other projects often come with an assumed solution attached (e.g. “Oh, we’re going to implement XYZ system, so we need you to write a couple of user stories”, leading to us having to work backwards to understand the problem).  Usually the brief is really broad (e.g. “Comply with the new Data Protection Act).

This leaves the BA with a significant amount of autonomy and latitude. There will be many ways of solving that problem, and defining the problem space is usually really fun and makes a huge difference to the success. The biggest challenge is people will often think that the impact is small, when actually it is actually far wider ranging. It’s therefore necessary to bring stakeholders along on the journey.

Although every compliance project is different, I typically find starting by identifying and having an understanding of the legislation or regulation is key. Of course, the BA does not need to be a legal expert, but we need to know enough to ask sensible questions and challenge. In many jurisdictions, legislation is written in (fairly) plain language, and you can even start to imagine some of the business rules/impacts that might be implied by it as you read it.


However, an important next step is to work with the relevant business and compliance stakeholders to determine the company’s interpretation of the legislation or regulation.  Rarely are these things completely prescriptive. You’ll find words like “appropriate” and “from time to time” and other phrases that show the intent without prescribing solutions. Particularly with new regulations this can be tricky, as there’s no existing convention or regulator judgements to base things on. Ultimately this is often a balancing act, and an area where good facilitation is key.

Ultimately, all of this leads us to a position where we can judge the impact on existing processes, applications, data and more. This is where the requirements or stories get written, but they will trace neatly back to an interpretation of a piece of the legislation or regulation. In many ways scoping can be easier on regulatory projects… a requirement either maps to a piece of the regulation or it doesn’t! (OK, it’s never quite that binary, but it is close).


Fringe Benefits

There’s still the challenge of selling regulatory projects to stakeholders. If we can’t get them excited about them, then there’s a chance their attention will wane and they won’t give us the input we need.

This is where our pain reliever/vitamin analogy comes in useful again. In fact, a good compliance project can be both.  A (hypothetical) project to comply with new data protection legislation might ensure we avoid million dollar fines (pain killer) while also providing us the opportunity to cleanse our existing data, so reports are more accurate (pain killer) and we have more flexibility on how we capture future data (vitamin).  This is just an example, but I am sure you get the gist.

So, have I changed your view of compliance projects? Either way, connect with me on LinkedIn and let me know. I’d love to hear your views!


What Apple’s Vision Pro Tells Us about User Stories

The Verge released a story recently reporting how early buyers of Apple’s Vision Pro “spatial reality” headset were already returning their devices to take advantage of Apple’s 14-day return policy window.

But why?

In this article, I’ll recap the issues sprouting up around this nonetheless revolutionary product in order to make a couple of arguments: 1) How Apple’s approach to hardware development may (to a fault) prioritize perceived quality over functional requirements, and 2) What user stories for a hardware/software product may necessitate to make future generations more viable for widespread adoption.


Problems Abound in VR, but Did Apple Put Form before Function?

The key issues cited for returns of the Apple Vision Pro are usability issues coupled with a hefty price tag (i.e., $3,500 MSRP).

That’s not to say buyers aren’t blown away by the revolutionary UI and what the device is capable of. Rather, users’ concerns are that—relative to the high price tag and usability issues—they simply can’t justify the expense for a device that presents these usability concerns. The price isn’t worth the experience, in other words.

Consider some of the tweets on X (formerly Twitter) from users describing their experiences with the device and ultimately their reasons for returning their headsets to Apple:

“Can’t wait to return the Vision Pro, probably the most mind blowing piece of tech I’ve ever tried. Can’t deal with these headaches after 10 minutes of use though,” tweets one user.

“Two hours after unboxing my Apple Vision Pro and using it, I decided to box it back up again and return it. It’s quite cool, but there’s nothing in it for me that I’ll use frequently enough to warrant my keeping it,” tweets another.

Virtual reality headsets are a complicated product category and represent an exceedingly difficult problem to solve considering the technical and physical challenges. I’ve reported on how, for example, ergonomics are a known issue.

Consider the problems a VR headset must address:

  • Weight – Obviously, a perfect solution doesn’t yet exist, but as some reviewers have reported, Meta’s redistribution of weight and use of pancake lenses in place of Fresnel lenses in their Meta Quest Pro represent an attempt to resolve UX problems their earlier Quest 2 presented. Considering that VR headsets aren’t a new category, reviewers may have liked to see a better first showing from Apple regarding the ergonomics issues related to weight distribution.
  • Price – With the $3,500 price tag (compared to $999.99 for Meta’s Quest Pro), price is an issue. Certainly, higher grade materials which play important parts of Apple’s industrial design philosophy and sustainability goals contribute to the heavier form factor compared to other headsets that rely on plastics. That said, alternative materials such as recycled plastics represent another way to reduce costs (e.g., potentially by 25-50%) while simultaneously addressing the weight issue.


User Stories and Understanding Evolving Needs

If you’ve seen the 2023 film, Blackberry, about how the once-dominant smartphone predating the iPhone (and later competitive offerings from Samsung), you know that the one thing the titular product from Research in Motion (the company that invented the product category) is that getting there first doesn’t mean staying there indefinitely.

The case of Blockbuster versus Netflix tells a similar story, where a giant who’s become the dominant force in the marketplace is complacent, slow to innovate (due to their complacency), and is disrupted.

In the case of Apple, they weren’t there first in the VR category. They also weren’t the first to the smartphone category, but in the case of the smartphone, they completely redefined the category.

Have they innovated enough while addressing known user problems in the category?

Certainly, Apple has created a revolutionary product, but as Mark Zuckerberg points out, the device doesn’t provide an experience so leaps and bounds ahead of its competitors that it warrants the price and the persistent UX problems.

In short: The Apple Vision Pro isn’t to the AR/VR product category what the iPhone was to the smartphone category.





What User Stories May Have Detailed: Ergonomics at the Center of Industrial Design to Solve Known User Problems

Chief among the user problems with the Apple Vision Pro is the ergonomics problem.

Considering the Verge report of customers returning their Vision Pro headsets with complaints of discomfort relative to the weightiness of the device for extended periods, it’s safe to say Apple hasn’t cracked the ergonomics problem on their first try.

But it’s also safe to say it’s a problem no manufacturer has truly solved, but Apple’s form factor doesn’t help. Consider, for example, how weight has been a known problem in VR applications studied by scholars.

Future iterations of these devices should seek to address the known ergonomics problems users are experiencing.


Example of Ergonomics-First Industrial Design

To stray away from VR headsets for a moment to talk just to ergonomics and how to approach solving real-world ergonomics problems, let me offer an example.

Heavy-duty power tools provide one real-world application where ergonomics are of heightened concern—we’re dealing with workers’ livelihoods and safety in situations that are inherently dangerous, after all. Characteristics of ergonomic power tools typically look to address a combination of weight, shape, and grip to provide a form factor that is as-comfortable-as-possible relative to the application.

Consider some of the common causes of musculoskeletal disorders like trigger finger (e.g., overexertion and repetitive motion) from a person’s finger becoming locked in a bent position as the result of repeatedly gripping and pulling the trigger of a crimper, for example.

Equipped with this known issue, the M18™ FORCE LOGIC™ 12 Ton Utility Crimper introduced a high-capacity muscle testing system to design the tool to require less than eight pounds of trigger release, which is 75% less than other crimpers, while also delivering an improved center of gravity and a significant weight reduction to the tool. What’s more, it requires 47% less muscle effort to use.

The example from Meta’s Quest Pro of redistributing the batteries to address the balance issue in earlier iterations is one that shows promise and Apple may take notice when addressing their own device’s weight problems.


Bottom Line

We may not have cracked the ergonomics problem associated with VR applications, but Apple may look at existing heavy hitters in the category, like Meta, as they tweak their own device’s shortfalls.

Outside of consumer applications, AR and VR offer exciting prospects for productivity enhancements in industries that could stand to gain in productivity like AEC: Studies have looked at the use of VR in safety training (e.g., articles have been published in Applied Sciences, additional research has been produced by California Polytechnic State University, and conference talks have been given on the subject).

If Apple can address the ergonomics and cost issues by prioritizing user needs, their Vision Pro headset may be the construction wearable of choice companies use to onboard new employees, train apprentices, and conduct safety demonstrations in the application to provide greater educational outcomes for the next generation of construction professionals.

Deep Dive Models in Agile Pt 2: Feature Trees

This short paper series, “Deep Dive Models in Agile,” provides valuable information for the Product Owner community to use additional good practices in their projects.

In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

Next up in this series is the Feature Tree. If you missed the first edition on Process Flows, you can find that here. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables and Business Objectives Models.

What is a Feature Tree?

A Feature Tree is an RML Objectives model that shows the full scope of features for a project or product on a single page in a tree format. A feature is just a short form description of the functionality provided by the project or product that brings value to the end user. The Feature Tree is great for bringing new people on a project up to speed and showing executives, business stakeholders, or customers all the features that are in scope for a project or release.

The Feature Tree is similar in shape to a fishbone diagram or an Ishikawa diagram but shows levels of features instead of root-cause analysis. It is easier to read than a flat list of features for a product because the Feature Tree groups them into logical buckets, but Feature Trees are very similar in function to Story Maps or Affinity Diagram which are also other ways to organize features visually for consumption. See an example Feature Tree below.


When would I use a Feature Tree on an agile project?

Feature Trees are useful for almost any agile project because they are just a good way to organize information about the project. The Product Owner (PO) or Business Analyst (BA) will usually elicit the start of a Feature Tree during a sprint 0 or planning type phase, possibly with information from a project charter or light-weight business case. From there, the PO or BA will organize the features into groupings, understand the connections between L1, L2, and L3 features and identify if there are any missing features. Depending on the story hierarchy you are using on your project, you might use Program Epic -> Feature -> Story or just Feature -> Epic -> Story for your L1, L2, and L3 features with the story level being optional (see illustration below).


Since you won’t always know the full scope of the product during sprint 0 or planning, the Feature Tree is always evolving, even throughout development, as the PO or BA finds new features to add to the backlog.

The Feature Tree also helps organize the hierarchy of your backlog as you know have an easy visual of how things are related.

Some ways Feature Trees are modeled to be especially useful on agile projects:

  • Color coding: the PO or BA can color code the features by release or sprint/iteration, which makes it easy to see at a glance if certain features are in or out of scope for a release
  • Prioritization by location: the PO or BA can order the Feature Tree such that more important items are closer to the “trunk” of the tree, allowing for visualization of the backlog prioritization
  • Gap Analysis or Current/Future State: instead of color coding by release, the PO or BA can color code for gaps or current vs. future state of the system (with red, blue, green or little-colored circles we like to call skittles)

How do I create a Feature Tree?

Like Process Flows, Feature Trees are one of the easier RML models to elicit and create. First, the PO or BA should find out if there are any existing lists of features for the project or product from a vision and scope document or a project charter.

From there, the PO or BA would host a brainstorming session to identify potential features and maybe even group them in an affinity diagram or story map. After that, the PO or BA would need to decide the format for their features. This paper is about the Feature Tree as a convenient way to organize the information, but a two level story map or affinity diagram will convey a lot of the same information (just perhaps not tie back to the backlog as well depending on the structure).

The model itself once the PO or BA has decided upon that format is pretty straight forward with only 2 elements:

Trunk/Product Concept– On the trunk of the Feature Tree is the Product Concept; this is a short form phrase that says what the product or project is. This will come from the Business Objectives Model which will be discussed in the next edition of Deep Dive.

Branches/ Feature- Coming out from the trunk are branches which have levels just like real tree branches. The largest branch type is the L1 features. Like the product concept, the L1 features will be described at a high level from the Business Objectives Model. These L1 features will be further broken down into L2 and L3 features (smaller branches) depending on your story hierarchy.

How do I derive user stories out of a Feature Tree?

Once the PO or BA has a good starting draft of the Feature Tree, the epics or features (again depending on your hierarchy) almost fall out of the Feature Tree. Each L2 or L3 branch becomes a feature, epic or story and each L1 branch becomes a Program Epic or Feature (based on SAFe or generic agile hierarchies). See example Feature Tree below:


So a feature for “Create Station” below might become the following epics/ features in your backlog:


Additionally, as mentioned above, you can add color coding to denote releases or sprints like below:



Feature Trees, like Process Flows, are super easy RML models to use on agile projects and derive features, epics, and user stories from because they organize the scope of a project or product onto a single page.

Executives, business stakeholders, and customer love this visual model because it shows them what is in and out of scope easily and potentially even shows them when they will get certain features. Developers and testers like the Feature Tree because it gives them the big picture of the entire project while they are working on specific user stories. Finally, the POs and BAs find this model useful for backlog population early in the project and maintenance throughout, so it is one of the most commonly used RML models on agile projects (second only to Process Flows!)

One note of caution is that because it is so easy to add additional features and scope to the Feature Tree and thus to the backlog, the PO or BA has to be vigilant in the management of the backlog to ensure that only the most valuable features get built for his/her project.

Deep Dive Models in Agile: Process Flows Pt 1

This short paper series, “DeepDive Models in Agile,” provides valuable information for the Product Owner community to use additional good practices in their projects.

In each paper in this series, we take one of the most commonly used visual models in agile and explain how to create one and how to use one to help build, groom, or elaborate your agile backlog.

The first in this series is the Process Flow. Other editions in this series will include: Business Data Diagrams, State Tables/State Diagrams, Decision Trees/Decision Tables, Business Objectives Models, and Feature Trees.

What is a Process Flow?

A Process Flow is an RML People model that describes the steps that a user takes to accomplish a goal or finish a task. This model is great for understanding the project’s current and future state processes of the business and understand those processes from the end user’s point of view.
RML Process Flows are created in levels in order to both be able to see the big picture of a process within a system as well as drill down into the details of a single more detailed process. This is in contrast to huge process maps with over 100 steps that try to show it all – but are unreadable! At the highest level, generally called the L1 level, the entire end to end process for an end user in a system is described, usually in 7-10 steps. This level tends to have no swim lanes or decisions to be made, so it is very abstract. See the top row in the example below:


From there, each step in the L1 process is broken down into the lower level processes, called L2 and L3 Process Flows. These are the levels that most people are comfortable talking about and eliciting. Each L2 or L3 process should be no more than 20 elements to keep readability, and even then should be divided by swim lanes to create smaller groups within the diagrams. L3 Process Flows are usually optional and are used if the process is large or complex of if there is a need to elicit that lower level of information to create requirements. See the example of an L2 and L3 Process Flow above.

When would I use a Process Flow on an agile project?

Process Flows are usually used for user-facing projects/systems, although their cousin, the System Flow, can be used in virtually the same manner to document system processes and logic.

When on an agile project, the Product Owner (PO) or Business Analyst (BA) will usually elicit the high-level process flow (L1) in a sprint 0 or planning type phase. From there, during that same planning type phase, the L2 processes to be created will be prioritized, and the PO or BA will usually work on the 1-2 highest priority process flows at the L2 level. This is to build the initial backlog.

Once in the developing phase or in the sprints themselves, the PO or BA will look ahead (usually 1-2 sprints ahead) and determine if additional L2 or L3 Process Flows need to be built to either identify new stories for upcoming sprints or elaborate (via L3 processes) those stories already identified.
This can continue until the project ends. Additionally, the PO or BA, when doing their planning for upcoming sprints, may need to update existing L2 or L3 Process Flows with new information that has come to light. In this case, that time should be built in as part of elaborating the stories, and a common set of Process Flows should be kept so that they are up to date!

How do I create a Process Flow?

Process Flows are one of the easier RML models to elicit and create. To elicit the information, the BA or PO should discuss with the users and stakeholder the processes in the system today, who performs them, and when. Users tend to naturally think about the steps they take every day so this is usually a pretty easy model to elicit.

During elicitation sessions, you can bring draft or strawman models, to generate commentary and ideas. You can also start from scratch with a whiteboard, post-it notes, and the users to create the process.

For future state, the PO or BA will generally start with the current state process flows and elicit information from the users/stakeholders on what will change or be different in the future system.

The Process Flow model itself for RML has roughly 7 element types, of which, we’ll only cover 4 or so today. The elements we are not covering here are forks, joins, and events. All of the elements are connected together by lines with arrows that show the direction of the flow.

Step – The step is the most used element, as it contains all the process steps. This is typically a rectangle with short phrases in the form of subject-action-noun phrase (User logs in). These sentences should be kept short to get the point of the step across without understanding every nuance.

Decision – This element is typically shown as a diamond and describes a decision the user must make to move forward in the process. Decisions are most commonly binary (Yes/No), but can be non-binary as long as the options are all mutually exclusive and collectively exhaustive. Every decision diamond needs at least 2 options coming from it to be a decision.

Swimlanes – Swim lanes describe either the user or group of users who performs the steps or the system in which a series of steps or decisions are taking place. The swim lanes for a single process flow should be all of one type (either user or system) to enable easier understanding. Swim lanes are a way to organize the steps in a Process Flow to focus attention and save space by not having to repeat the user or system in each step.

Incoming/Outgoing Elements – Since RML Process Flows are built in levels, every lower level (L2 or L3) Process Flow should have an Incoming and Outgoing element. These elements are the “You are here” for the Process Flow set. They tell you what process step immediately preceded the current process and where the reader will go next.

How do I derive user stories out of Process Flows?

Once the PO or BA has good draft Process Flows to work with, he can start deriving stories out of the Process Flows to build or add to his backlog.

The level of story derived depends on the level of the Process Flow and the complexity of the process. In most cases, each step in an L1 Process Flow becomes at least one Epic user story (too big to fit into a single sprint). Each step in an L2 or L3 Process Flow becomes one or more User Stories for the backlog, and each decision can be as few as 1 user story or as many as 7 user stories. See the examples below.



Because user stories are written from the user’s point of view and Process Flows are created from the user’s point of view, Process Flows lend themselves very easily to identifying user stories. For example, if the Process Flow step is “User logs into the system,” then the user story is very similar and might look like “As a User, I want to be able to log into the system so that I can access my account information.”

Decisions are a little more confusing because if it is a lower level decision (say in an L3 Process Flow), it might be one story with the decision lines being acceptance criteria. If it is an L2 Process Flow, the decision might lead to a story for each branch of the decision diamond. For this, the PO or BA will have to use her knowledge of the team and the process to decide what is best for slicing up the stories.


Process flows are one of the easiest RML models to derive user stories out of because they are from the user’s point of view and allow the PO or BA to walk through a process systematically and write user stories for each step that needs to be supported.

However, one final point is that these Process Flows don’t need to be perfect or complete to be useful. The PO or BA can draft a process flow, review with users or stakeholders, and derive user stories from an incomplete one. As long as there is traceability between the process steps and the user stories, it is easy to know what to update if the process changes or where the gaps are if new steps are added. Additionally, even team members other than the PO or BA can edit and update the processed if they live in a centralized location.

In the end, these are one the most useful models we find on customer facing agile projects because they are quick to make and update and lend themselves very easily to stories at all levels of the agile requirements hierarchy.