Tag: User Stories

User Stories Without Users: The Pitfalls of Assumption-Driven Design

Written by Adrian Reed on September 12, 2024. Posted in Articles.

Where I live, every year residents receive two water bills. One is for the fresh (tap) water supply, the other is for wastewater and maintenance of sewers. The wastewater bill is a standard tariff, and I guess most people have automatic monthly payment set up. It’s the kind of thing you “set and forget about”. I mean, it’s hard to get too excited about wastewater, right?

Recently, I’ve been receiving letters from the water company trying to get me to sign up for their online portal (or app) so that I can get my bills electronically. I can almost imagine the initial user story that was written:

“As a user, I want to access my annual statement online, so that I know how much I’ll be charged”

Yet, for me at least, this is an illusion. I really don’t need another app, I really don’t need another portal account and password. For something I receive once a year there is a good chance I will have forgotten my password by the time I need to use it, and if I’m completely honest I look at about 10% of the statement anyway (I glance at the monthly payment amount then file the statement).

These days I’m a digital native, but having to access this information via an online portal would be less convenient for me. I suspect I’m not the only consumer that thinks this…

Digitalization with Purpose

I’m not saying that portals and apps aren’t useful, they absolutely are in the right context. I use online banking apps and portals all the time, and these save me time. However, I wonder how many customers the wastewater company spoke to before building their app/portal. I wonder whether they determined whether customers actually wanted it or not?

Another possibility is that this wasn’t a customer-driven initiative at all. Perhaps the director of customer service was given a target of reducing cost. One way of doing this is to reduce the amount of letters and statements that are printed. Every statement costs money: the paper, printing, envelope, postage cost plus the cost of handling it too.

But when the change is purely driven from an internal cost-saving perspective, with little or zero customer interaction, isn’t it a little disingenuous to write a “user” story from the perspective of the customer? A customer who hasn’t been consulted? There’s the danger we jump straight to a solution, and with no customer interaction this might be a solution that has very low adoption.

Understand the Real Drivers

So, if the driver is cost reduction say so. Rather than jumping straight to a user story or set of requirements, a more useful starting point will be to understand the specific outcomes that are being sought. In this case, it might be:

“A reduction in cost of sending and handling outgoing correspondence of X%”

Then, it’s useful to understand any constraints. There is likely to be a regulatory requirement to issue an annual ‘statement’ (although what a ‘statement’ is may or may not be prescribed in the regulations). With these things in mind, existing practices can be challenged.

Then, having understood why a change is necessary in the first place, we can start to work with the stakeholder team (including customers or customer representatives) to figure out ways that this can be achieved that will ideally benefit them too. Or, at least ways that they can live with.

This might create a very different set of solutions. Perhaps a solution is proposed where a customer receives a small discount for the first year when they opt in to having electronic statements. They’ll receive an SMS text message with the key details (payment amounts, dates) and an email reminding them that the statement information is there if they want it. This is just one option: it’s one that would work well for me, but I am a sample of one. It would be important to get a range of views from different stakeholder groups.

Understand Variety

When thinking about changes like this, it’s also important to consider those who can’t engage with organizations digitally. There can be many reasons for this, so thinking about accessibility not just in terms of “how can we make the digital solution accessible” but also “what are our options for non-digital engagement” is important. Understanding the variety of people, their needs and preferences is important.

In conclusion, whatever final solution is agreed upon, starting by understanding the desired outcomes (and being transparent when the primary goal is cost saving) will lead to a broader conversation. It’s important to avoid rushing towards an early solution in absence of this!

Beyond Jargon: Bridging the Gap Between Precision and Clarity

Written by Adrian Reed on June 13, 2024. Posted in Articles.

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

Written by Adrian Reed on May 20, 2024. Posted in Articles.

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

Written by Lucas Marshall on March 6, 2024. Posted in Articles.

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

Written by Candase Hokanson on October 5, 2016. Posted in Articles. 1 Comment on 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:

Conclusion

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.