User Stories | 10 Tips For Writing Good User Stories

10 Tips For Writing Good User Stories
Roman Pichler | Mar 07, 2022 (Update)

1 Users Come First
2 Use Personas to Discover the Right Stories
3 Create Stories Collaboratively
4 Keep your Stories Simple and Concise
As <persona>,
I want <what?>
so that <why?>.

5 Start with Epics
6 Refine the Stories until They are Ready
7 Add Acceptance Criteria
8 Use (Paper) Cards
9 Keep your Stories Visible and Accessible
10 Don’t Solely Rely on User Stories

Author = Roman Pichler


Tools | 13 product management tools the best Product Managers use

13 product management tools the best Product Managers use
Medium | Apr 01, 2022

Always good to get a refresher on what is being used by others. Which tools do you use?

Phase 1: Opportunity identification and validation
(1) Google Sheets (Spreadsheets)
(2) Notion (Taking Notes)
(3) Field (Collect, Explore, Present)

Phase 2: Design and prototyping
(4) Miro (Collaborative Whiteboard)
(5) Figma (Collaborative Design & Prototyping)
(6) Pen & Paper
(7) Pitch (Collaborative Presentations)

Phase 3: Feature development
(8) Confluence (Team Workspace)
(9) Jira integration (Agile Software Development)
(10) Google Docs (Drafting Documents)
(11) Trello (Productivity)

Phase 4: Launch and continuous iteration
(12) UXCam (Analytics – Note: plug)
(13) Grammarly

Author = Jane Leung, UXCam

UX | 10 Examples of Good User Experience (UX)

10 Examples of Good User Experience (UX)
trone | Undated (Summer 2021 or before)

Websites & Apps that Understand Humans

  1. Rover: Using Reviews to Build Trust |
  2. Duolingo: Tearing Down Roadblocks |
  3. Paypal: Letting Simplicity Rule | (Mobile App)
  4. MailChimp: Humanizing Technology | (Note: Intuit acquired MailChimp in Q4/2021, the current interface does not reflect the article, which predates the acquisition).
  5. Starbucks: Making it Personal | (Mobile App)
  6. Google: Loading Super Fast Since 1997 |
  7. Simple: Adding Clarity and Digestibility to Finance | (Mobile App)
  8. Nest Thermostat: Invisible Design | (Physical Product & Mobile App)
  9. Habitica: Using Gamification for Productivity |
  10. Yelp: Everything Findable |
  11. Bonus Example: From the Internet Archive (Poncho)

Author = Laura Flugga (trone)


Roles | The Product Owner

HA #38: AMA session with Roman Pichler: The Product Owner | 58 minutes
Age Of Product | Feb 08, 2022

Stefan Wolpers’ Hands-on Agile #38: AMA w/ Roman Pichler: The Product Owner | 58 minutes

Stefan Wolpers’ AMA session with Roman Pichler on the role of the Product Owner.
Speaker: Roman Pichler | Host: Stefan Wolpers

My Notes:

Product Owner = Accountable for maximizing the value of the product
(Scrum Guide 2020)

What is a Product? An asset that creates value for
The users and customers
The company developing & providing it
(Searching for a product online = feature, not product)

What does it mean to own a product? It means
Being empowered to make strategic and tactical product decisions (own a product holistically, cf. Full Stack ownership)
Being responsible for achieving product success

Ownership Depth
Vision = what we want to achieve
Strategy = approach to get there
Tactics = information in the product backlog
Scrum Product Owner = Full stack ownership Vision/Strategy/Tactics
Product Manager in an Agile Context or Agile Product Manager
Compare w/ Partial Ownership
(SAFe = example) Product Owner = more a tactical role => product backlog, more inward facing, close to the Dev Team => Only partial ownership
(SAFe = example) Product Manager = for the Vision & strategic role

3 Scaling options
How to make it work? Get together and discuss it

About the Business Analyst

Characteristics of a great Product Owner
Professional PO (=> focus on the role of PO)
Committed to the Product, to the People, to the Process

About the Right Leadership

Backlog Management
Product Goal => only items that serve the product goal
Not too big, not too fast
Tie product backlog to product roadmap
Sometimes easier to start from scratch than try to make sense of a too large backlog (like thousand+ items)

Big products => Cascading goals
Mission statement
Challenge = Formulate the right goals & connect them in a meaningful way

Authors = Roman Pichler & Stefan Wolpers


Roles | 10 Steps to Becoming a Great Agile Coach

The 10 Steps to Becoming a Great Agile Coach | 58 minutes
LeadingAgile | April 2020 (TriAgile 2020)

The 10 Steps to Becoming a Great Agile Coach | 58 minutes

In this remote talk from TriAgile 2020, LeadingAgile CEO Mike Cottmeyer uncovers the 10 steps you can take to become the great Agile coach you always wanted to be, along with the four primary skill areas that make a great coach and the hard skills you’ll need to develop to get there.

Primary Skill Areas That Make a Great Coach
#1 Developing Hard Skills
#2 Getting The Right Experiences
#3 Fitting In To Your Company Culture
#4 Being A Good Community Citizen
#5 Recognizing Your Belief System
#6 Understanding Your Default Behaviors
#7 Developing Emotional Intelligence
#8 Learning To Think Fast On Your Feet
#9 Working Through Solutions
#10 Pattern Recognition, Systems Thinking, and Planning
Coaching Roles at LeadingAgile

Author = Mike Cottmeyer


UX | UX Storyboard Creation: Complete Guide

UX Storyboard Creation: A Complete Guide For Beginners
uxstudio | Mar 12, 2019

UX storyboard creation seems like a slightly overlooked design technique. We all know the value of user interviews or personas. We agree that testing is a crucial part of product design. In contrast, people do not commonly use storyboarding, even though it can help in many situations. As a true fan of the technique, in this guide, I want to walk you through all the whys and hows of UX storyboard creation. Plus, I even made a free template for you to get started!

What is a storyboard?

Storyboards in product design
We have personas and journeys. Why do we need UX storyboard?

  1. Visual benefits
  2. Emotional engagement
  3. Memorability
    When to storyboard?
  4. During the discovery phase of a new product
  5. While building the product
    Typical scenarios
  6. Mapping a whole service
  7. Digital product with offline events
    Important note: Drawing skills don’t matter!

How to design a first UX storyboard

  1. Step one – Get some data!
  2. Step two – Pick a flow to focus on
  3. Step three – Write down the plot steps and basic outline of the story
    The main character
    Plot Steps
    For some guidance at this stage, feel free to download our free Storyboard Template:
  4. Step four – Add emotions and scene details
  5. Step five – Create the storyboard!

Author = Luca Morovián (uxstudio)


Planning | The Cone of Uncertainty

Cone of Uncertainty
Agile In A Nutshell | Undated

The Cone of Uncertainty, described by Steve McConnel, shows that at the beginning of any project we don’t know exactly how long a project is going to take.

Dealing with the cone
Pad the estimate
Size the project relatively
Be upfront and honest
Fund incrementally
The Root Cause

If you find yourself getting tripped up by the cone of uncertainty, just remember the whole point of software estimation is to determine whether the project is even possible.

Or as Steve McConnell says: The primary purpose of software estimation is not to predict a project’s outcome; it is to determine whether a project’s targets are realistic enough to allow the project to be controlled to meet them.
—Steve McConnell, Software Estimation: Demystifying the Black Art

Author = Jonathan Rasmusson (Agile In A Nutshell)


User Stories | Atlassian Examples

User stories with examples and a template
Atlassian | Undated

User stories are development tasks often expressed as “persona + need + purpose.” 

What are agile user stories?
A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective.
A user story is an informal, general explanation of a software feature written from the perspective of the end user or customer.

Stories fit neatly into agile frameworks like scrum and kanban. In scrum, user stories are added to sprints and “burned down” over the duration of the sprint. Kanban teams pull user stories into their backlog and run them through their workflow. It’s this work on user stories that help scrum teams get better at estimation and sprint planning, leading to more accurate forecasting and greater agility. Thanks to stories, kanban teams learn how to manage work-in-progress (WIP) and can further refine their workflows.

Why create user stories?
User stories serve a number of key benefits:
Stories keep the focus on the user. A to-do list keeps the team focused on tasks that need to be checked off, but a collection of stories keeps the team focused on solving problems for real users.
Stories enable collaboration. With the end goal defined, the team can work together to decide how best to serve the user and meet that goal.
Stories drive creative solutions. Stories encourage the team to think critically and creatively about how to best solve for an end goal.
Stories create momentum. With each passing story, the development team enjoys a small challenge and a small win, driving momentum.

How to write user stories
Consider the following when writing user stories:
Definition of “done” — The story is generally “done” when the user can complete the outlined task, but make sure to define what that is.
Outline subtasks or tasks — Decide which specific steps need to be completed and who is responsible for each of them.
User personas — For whom? If there are multiple end users, consider making multiple stories.
Ordered Steps — Write a story for each step in a larger process.
Listen to feedback — Talk to your users and capture the problem or need in their words. No need to guess at stories when you can source them from your customers.
Time — Time is a touchy subject. Many development teams avoid discussions of time altogether, relying instead on their estimation frameworks. Since stories should be completable in one sprint, stories that might take weeks or months to complete should be broken up into smaller stories or should be considered their own epic.
Once the user stories are clearly defined, make sure they are visible for the entire team.

User story template and examples
“As a [persona], I [want to], [so that].”

Breaking this down:
As a [persona]“: Who are we building this for? We’re not just after a job title, we’re after the persona of the person. Max. Our team should have a shared understanding of who Max is. We’ve hopefully interviewed plenty of Max’s. We understand how that person works, how they think and what they feel. We have empathy for Max.
Wants to”: Here we’re describing their intent — not the features they use. What is it they’re actually trying to achieve? This statement should be implementation free — if you’re describing any part of the UI and not what the user goal is you’re missing the point.
So that”: how does their immediate desire to do something this fit into their bigger picture? What’s the overall benefit they’re trying to achieve? What is the big problem that needs solving?

Author = Max Rehkopf


UX | Good User Experience For Mobile Apps (+ Tool)

What makes a good user experience for my mobile app?
Mopinion | 16 Feb 2017

Provide an efficient onboarding
Offer Assistance
Invest in usability
(…) to prevent your customers from leaving the app, you must adhere to certain rules:
Use a clear search bar at the top of the app that brings up search suggestions and search history
Organise and label the ‘menu’ category so that your customer can take a quick glance and see which category they need
With ecommerce apps, always make sure there are good filters for the products and services so that the customer can filter by price, color, size, etc.
Forms: Do you work with ordering funnels and long forms in your app? Nothing is more frustrating than having to fill in all of that information again because you missed a section. It is better to highlight the data that is filled in incorrectly or not filled in at all so that your customers will see right away what needs to be adjusted.
Assure Security And Trustworthiness
Don’t spam your users with notifications
Use customer feedback

Have you tried the Mopinion for mobile apps?
Plug / Tool = Mopinion SDK for Apps = User Feedback
Grab a hold of powerful in-app insights
Collect powerful feedback from your native apps with our flexible and easy-to-install SDKs for iOS and Android.

Author = Erin Gilliam Haije (Mopinion)


User Stories | Assumptions, Risks, & Dependencies

Assumptions, Risks, and Dependencies in User Stories
DZone (Agile Zone) | Mar 06, 2019

Don’t gamble with your project. Learn where these three often hidden elements may be in your user stories and how they can derail your project.

An assumption in requirements is an assertion on which a given requirement or set of requirements depends.
There are 3 fundamental problems with assumptions:
An assumption is not quantified in terms of likelihood. It is nakedly stated as a fact.
An assumption is not quantified in terms of impact. “What happens if this isn’t true?” is not part of the structure of an assumption.
An assumption has no required or inherent follow-up. In my experience, assumptions are frequently placed in requirements documents and then forgotten about. It is “assumed” that someone has added a tickler in a project plan to check on the status of an assumption, but that frequently doesn’t happen.

Assumptions were a way of attempting to formalize connections to external conditions (systems, tasks, states, etc.) that would later be called dependencies.

A dependency is simply a connection between two items (often tasks or teams, but can also apply to components, modules, or other software structures). A dependency asserts that the dependent (client) state cannot change (start or finish) until the dependency (precedent) reaches a certain state
. There are four types:

Start/Start – item A can’t start until item B starts. Cars in a motorcade can’t begin moving until the lead car begins to move. In fact, each car in a motorcade can’t move until the car immediately in front of it moves.
Start/Finish – item A can’t start until item B finishes. The second stage of a rocket can’t fire until the previous stage has finished.
Finish/Start – item A can’t finish until item B starts. Less common in software development, but an example would be an evening security guard who can’t end his/her shift until the guard on the next shift clocks in and begins their shift.
Finish/Finish – item A can’t finish until item B finishes. My accountant can’t finish our income tax preparation until we have finished assembling all requisite data from the year.

Dependencies have similar problems to assumptions, though to a lesser degree.

Generically, a risk is something Bad that might happen (in this context we add “…that affects the timely and correct implementation of software”). More formally (at least in Project Management circles), a risk is a potential negative condition that can be quantified in two dimensions:
How likely is this condition to occur?
What is the impact should this condition occur?

It is important to note at this point that risks should be identified which affect the project, not the company.

It’s also useful to note how well this approach (originating in Project Management) dovetails with Agile. Identifying and quantifying risk gives Agile teams the ability to prioritize tasks. Some people are insistent that risk is a potentially negative external condition that can affect a project. But internal risks need to be identified and quantified as well.

Which brings up the second beneficial aspect of using the Project Management approach to risk: it requires the creation of a plan to mitigate any negative impact on the project. This has an implication that isn’t immediately obvious: risks that can’t be mitigated are effectively not risks.

Since dependencies are a form of risk, it stands to reason that they should be included in any mitigation plan.

Train your teams to avoid the use of assumptions in user stories, use cases or any requirements document. Excise existing assumptions from such documents by examining each one in detail, then either a) removing the assumption unilaterally, or b) converting the assumption into a risk or dependency.
Use dependencies specifically to document the order of events, steps or stages (not components), and be clear about how the term is being used. Treat all dependencies as risks.
Use risk to quantify likelihood and impact, using whatever scale is appropriate for your organization. Use the term and scale consistently across teams and projects.
Establish a mitigation plan for (at least) high-priority risks.
Remove any identified risks that have no possibility of mitigation, most effectively by bumping it up to any architectural planning group that oversees long-term development practices.

Author = Tom Fulton (Agile Zone)