Author: beckycarter

Posted in Scrum Add-ons

Creating a New Product Backlog

Posted on by beckycarter

Gathering Requirements

Trawling for Requirements (1, pg 43)

Imagine gathering requirements as like fishing. You don’t want to catch every single fish in one haul as the processing of that would mean that some fish would go off. Focus on catching the big fish first by using a wide net, then later you can use a finer net to catch the smaller fish. This is the same with requirements as with the big requirements you can use them to understand the product direction better.

Building the Initial Backlog Techniques

Idea Generating Workshop (2, pg 50)

  • Use the liberating structure, 25/10 Crowd Sourcing
  • Ask the room to use the ‘What’s the most important feature this product needs to be successful?’ question
  • The output of the session can be used by the Product Owner to form the initial Product Backlog

User Story Mapping (4)

Impact Mapping (3, pg 86)

Technique for connecting PBIs back to the goals they are intended to meet.

Impact Mapping

References

  1. User Stories Applied by Mike Cohn
  2. Fixing Your Scrum by Ryan Ripley and Todd Miller
  3. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  4. User Story Mapping by Jeff Patton
Posted in Scrum Add-ons

Design Studio Workshop

Posted on by beckycarter

What

This workshop is a team activity to design the UX for a product/ feature with any team members regardless of design expertise.

Who

  • 5 – 8 people recommended 
  • Larger than 8 could be wise to run parallel sessions

Supplies

  • Pens 
  • Pencils
  • Felt-tip markers or similar
  • Highlighters (multiple colours) 
  • Sketching templates (can be blank sheets of A3 divided into 6 segments) 
  • A1 self-stick easel pads
  • Dot stickers 

Process

  1. Problem definition and constraints 
    • Ensure everyone is aware of the problem you are trying to solve
    • Everyone understands the assumptions 
    • Everyone knows the users you are serving
    • The hypotheses you’ve generated
    • Constraints in which you are working
  2. Individual idea generation (diverge) 
    • Give each person a sketching template
    • If people find prospect of a blank page daunting optionally add a step whereby everyone writes the name of a persona/ pain point in each one (can repeat) and spend 5 minutes doing this
    • Give everyone 5 minutes to generate 6 low-fidelity sketches of solutions
    • These should be visual articulations, not words
    • If you can draw a square, a circle, and a triangle you can draw any low-fidelity diagram
  3. Presentation and critique 
    • 3 minutes per person
    • Go around the table
    • Each person holds up their sketches and presents them to the team
    • Presenters should state who they were solving a problem for and which pain point they were addressing and then explain the sketch
    • Each member of the team should provide critique and feedback to the presenter
    • Feedback should be focused on clarifying the presenter’s intention – no opinions allowed as they get people defensive and provide little clarity
      • How does this address the persona’s problem?
      • I don’t understand that part. Can you elaborate?
  4. Iterate and refine in pairs (emerge) 
    • 10 minutes
    • Each pair has an A3 sheet
    • Pair up (it is a good idea to pair up with someone with similar ideas if there is someone)
    • Each pair will be working to refine their ideas
    • Goal is to pick ideas that have the most merit and develop a more evolved, more integrated version of those ideas
    • Get more specific here, more details
    • Once time is up do the Present and Critique section again
  5. Team idea generation (converge) 
    • 45 minutes 
    • The team must converge on one idea 
    • The goal for this idea is to be the best for success an to be the basis for forming an MVP and running experiments
    • Use the easel pads or a whiteboard for the idea
    • Sketch components and workflow
    • Will need to compromise and pare back features 
      • Any ideas that don’t make the cut this time go into a parking lot to make it easier to let go of ideas
    • Put the output of this in a visible central place 

References

  1. Lean UX by Jeff Gothelf, pg 52 – 57
Posted in Scrum Add-ons

User Interviews

Posted on by beckycarter

Who to Interview

How many customers should I test with? (2, pg 144)

  • Focus groups lead to participants not being fully honest 
  • Interview between 5 and 8 is a good balance

How to recruit in target market? (2, pg 148)

  • Refer to personas created to help with writing screener questions 
  • Ensure to cover all of the segmentations you used forming your target market
  • Use conferences/ networking events

Starbucks User Testing (2, pg 151) 

  • Low cost and immediate
  • Harder to screen for the customers that you actually want (demographic)
  • “Hi sir, do you have 10 minutes to share your feed back on a new website in exchange for a £20 Starbucks card?
  • More success found in shopping centres than Starbucks as people tend to have more time to kill

How to Interview

In-person, remote, and unmoderated user testing (2, pg 145)

  • Moderated tests have the customer perform the test on their own, but recorded for the moderator to view afterwards
  • In-person allows richer data collection (body language)
  • Remote – be aware of technology issues of screen sharing 
  • Unmoderated can product a quick turn around as providers already have users lined up ready 

Question Guidance

Open vs Closed Questions (2, pg 158)

  • Open usually begin with why, how and what 
  • Closed questions limit the customer’s possible responses (e.g. to yes or no)
  • Tip to write the questions down in advance to check they are open

Non-leading Questions (2, pg 158 – 160)

  • Be careful not to tell the user how you would like them to respond, e.g. ‘how would you prefer it to be sorted? By date?’  
  • Be ok with long pauses and don’t help them as it will invalidate the test. Real users won’t have you to help them.
  • Don’t predict what the customer will say out loud and try to recede into the background to get the most honest feedback

Measuring Importance and Satisfaction (2, pg 59)

  • A bipolar scale goes from negative to positive (i.e. satisfaction)
  • A unipolar scale is a matter of degree (i.e. importance)
  • More than 10 choices is overwhelming
  • Fewer that 5 will lack granularity
Unipolar Example
  1. Not at all important 
  2. Slightly important 
  3. Moderately important 
  4. Very important 
  5. Extremely important 

Bipolar example 
  1. Completely dissatisfied 
  2. Mostly dissatisfied 
  3. Somewhat dissatisfied 
  4. Neither satisfied nor dissatisfied
  5. Somewhat satisfied 
  6. Mostly satisfied
  7. Completely satisfied

Product Market Fit Question (Sean Ellis) (2, pg 231)

  • Do not invest in trying to grow a business until after you have achieved product-market fit
  • This questions helps you assess if you have achieved product-market fit
  • Survey users and ask:
    • “How would you feel if you could no longer use product X?
      • Very disappointed
      • Somewhat disappointed 
      • Not disappointed (it isn’t really that useful)
      • N/A – I no longer user (product X)”

Follow-up Questions (2, pg 157)

  • ‘Echoing back’ is a useful technique – e.g. ‘I see you clicked that button. Could you tell me why?’
  • If user asks question, ask another question rather than replying with yes or no

The Data

Make sense of the data (1, pg 103) 

  • Look for patterns 
  • Place outliers in a parking lot (outliers could form their own pattern with more data collection so don’t bin them) 
  • Verify with other sources (do people inside the office agree/ customer support staff seeing the same trend) If not your sources could have been skewed 

Feedback Table (2, pg 162)

Feedback Structure (2, pg 162)
  • Group into feature set, UX design, and messaging
  • Ask valuable and easy to use questions
  • Get overall scores to compare to next wave when improvements have been made

Regular Cadence

TIP – randomly schedule users on a routine basis so that you always have some ready to test with, rather than panicking (2, pg 150)

Continuous Learning in the Lab: Three, Twelve, One (1, pg 99)

  • Three users, by Twelve noon, once a week
  • The regular cadence ensures that you ‘test what you’ve got’ so that there is no deadline pressure
MONDAYTUESDAYWEDNESDAYTHURSDAYFRIDAY
Start with the recruiting process
Decide what will be tested		Refine what will be testedRefine what will be tested
Write the test script
Finalise recruiting		Testing day
Review findings with the entire team		Plan the next steps based on findings
Three, Twelve, One Sequence (1, pg 99)

References

  1. Lean UX by Jeff Gothelf
  2. Lean Product Playbook by Dan Olsen
Posted in Scrum Add-ons

UX

Posted on by beckycarter

UX Principles

Two Elements of UX Design (1, pg 115)

  • Great UX design = Usability + delight
  • Usability = can customers use your product?
  • Delight = do customers enjoy using your product?

Olsen’s Law of Usability (1, pg 113) 

'The more user effort required to take an action, the lower the percentage of users who will take that action. The less user effort required, the higher the percentage of users who will take that action.'

Gestalt principles (1, pg 136)

Principle of proximity – the brain perceives objects that are closer together as more related than objects that are farther apart

Principle of similarity – the brain perceives objects that share similar characteristics as more related than objects that don’t share those characteristics

Visual Hierarchy Design Principle (1, pg 136)

  • The brain assumes larger objects are more important and smaller objects are less important 
  • Elements with high contrast (e.g. items that ‘pop’) are more important 
  • Position also affects visual hierarchy (e.g. for people who speak English the top left is the most important as that is how we read) 
  • To determine visual hierarchy squint at the page you will be able to identify the most important design elements

Principles of composition (1, pg 137) 

  • Unity – does the page or screen feel like a unified whole or a bunch of disparate elements?
  • Contrast – is there enough variation in colour, size, arrangement, and so forth to create visual interest?
  • Balance – have you equally distributed the visual weight (position, size, colour etc) of elements in your design?
  • Use of space – how cluttered or sparse does your design feel? Ensure there is enough white space so that it doesn’t feel crowded.

UX Components

UX Design Iceberg (1, pg 116)

UX Design Iceberg (1, pg 116)
Conceptual design (1, pg 117)
  • This is the core concept you are using to design your product 
  • E.g. uber’s is based around a map
Information Architecture (1, pg 120)
  • How the information and functionality should be structured 
  • Findability – how easy it is to find what the user needs (test this) 
  • Sitemaps are tool used to define the structure
Interaction Design (1, pg 123)
  • Specify user flows 
  • What actions can the user take?
  • Including error messages and slow response flows
  • Flowcharts are a tool for mapping flows 
  • Wireframes are tool for testing
Visual Design (1, pg 129)
  • Colours/ font/ graphics have emotions for user
  • Style guide used to ensure consistent feel 
  • Layout grids used to ensure consistent alignment of the design (e.g. divide the desktop screen by 12 sections which is then used to put all the nav options/ content boxes in line with) (page 133)
  • Mockups used to test this 

References

  1. Lean Product Playbook by Dan Olsen
Posted in Scrum Add-ons

Product Backlog Refinement

Posted on by beckycarter

Overview

Definition: Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog.

Length: “Refinement usually consumes no more than 10% of the capacity of the Development Team” (1)

People: Product Owner, Development Team

Outcome: Product Backlog items become more transparent through refinement and the top items are deemed ‘Ready’ for a Sprint (i.e. can be ‘Done’ by the team within one Sprint)

Benefits

Product Backlog Refinement Benefits (2, page 103, Mastering Professional Scrum)

  1. Increased Transparency – adding details for what you plan to deliver, and your progress
  2. Clarification of Value – outcomes of what you are trying to achieve become clearer, and helps the team to build the right thing
  3. Breaking things into consumable pieces – increases flexibility for the team to meet ‘Done’ in a Sprint
  4. Reduction of dependencies
  5. Forecasting
  6. Incorporation of learning – gained learning is incorporated into the product

Facilitation Techniques

Fishbowl collaboration (3)

  • Three – five people collaborate around a whiteboard (the fish in the bowl)
  • Others in the room may observe but are not allowed to speak
  • If someone from outside the bowl wishes to speak they can dive into the bowl which bounces out one of the fish already in the bowl
  • People can leave anytime if they are not finding it valuable
  • This technique keeps the conversation small and productive

Three Amigos and BDD

  • Backlog Refinement is attended by someone to represent each discipline in rotation (i.e. Three Amigos of Product, Development, Testing)
  • Behaviour Driven Development is used to focus the conversation on the behaviour of the User Story
  • See my talk notes

References

  1. The Scrum Guide
  2. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  3. User Story Mapping by Jeff Patton
Posted in Scrum Add-ons

Business Value/ Vision

Posted on by beckycarter

Business Value Levels

Strategy Deployment Levels (1, pg 75)

VisionWhat do we want to be in 5-10 years? Value for customers, position in market, what our business looks likeCEO/ Leadership
Strategic IntentWhat business challenges are standing in the way of reaching our visionSenior leadership
Business leads
Product InitiativeWhat problems can we address to tackle the challenge from a product perspective?Product leadership team
OptionsWhat are the different ways I can address those problems to reach my goals?Product Dev teams
Strategy Deployment Levels

Business Value Types

Framework for thinking about value by Joshua Arnold (1, pg 82)

Increase Revenue – Increasing sales to new or existing customers. Delighting or Disrupting to increase market share and size

Protect Revenue – Improvements and incremental innovation to sustain current market share and revenue figures

Reduce Costs – Costs that we are currently incurring, that can be reduced. More efficient, improved margin or contribution

Avoid Costs – Improvements to sustain current cost base. Costs we are not currently incurring but may do in the future

Type of Value (3)

Commercial Value: How much revenue or profit does this work result in?

Market Value: How many new customers will we be able to serve?

Efficiency Value: How much time or money will this save us?

Customer Value: To what extent will this decrease the likelihood that a customer leaves?

Future Value: How much will this save us in time or money in the future?

Project Rather than Product Management Smell

Build Trap (1, pg 1)

Build Trap = organizations become stuck measuring their successes by outputs rather than outcomes. […] When companies stop producing real value for the users, they begin to lose market share, allowing them to be disrupted.

Progress Focus Powerful Questions (2, pg 80)

For when a company is focusing on percent complete, status, or points rather than value

  • Could we achieve all of these measure and still be unsuccessful?
  • How are we validating assumptions about the user needs of the market demand?
  • What are we learning about value? How I this guiding our product decisions?
  • What has changed with our users or our competitive environment since we began this initiative?

References

  1. Escaping the Build Trap by Melissa Perri
  2. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  3. What is This Thing Called ‘Value’? by Christiaan Verwijs (blog post)
Posted in Scrum Add-ons

Roadmaps

Posted on by beckycarter

Components

Key parts to roadmaps (1, pg 150)

  • The theme
  • Hypothesis
  • Goals and success metrics
  • Stage of development
    • Experiment = is the problem worth solving? Problem Exploration and Solution Exploration phase (no code)
    • Alpha = is the solution desirable? Minimum feature set for a robust solution experiment, in code, for a small set of users
    • Beta = is the solution scalable? Solution is available to more people (not all) to test technical abilities of scaling.
    • Generally Available (GA) = solution is available to all and sales team can start openly talking about it
  • Any important milestones

Further Reading

  • C. Todd Lombardo and Bruce McCarthy’s book – Product Roadmap Relaunched (1, pg 150)

References

  1. Escaping the Build Trap by Melissa Perri
Posted in Scrum Add-ons

Prioritising Features/ Backlog

Posted on by beckycarter

How to Prioritise the Backlog

Priority Process (1)

  • Firstly on business value
  • Secondly with the team to include impediments
  • This produces the most important thing to the business
  • Business value over schedule driven decisions

Exercises for Backlog Prioritisation

Exercise to help prioritise the Product Backlog (2, pg 55)

  • Use the liberating structure, Min-Spec
  • Display the Product Backlog in the room
  • Use the question of ‘Which features in our product backlog are needed in order to have a successful product release?’
  • Test the list generated against the question ‘If we delivered all of out must-do PBIs except this one, would we still have a successful product release?’

References

  1. Coaching Agile Teams by Lyssa Adkins
  2. Fixing Your Scrum by Ryan Ripley and Todd Miller
Posted in Scrum Add-ons

Value Statements

Posted on by beckycarter

Communication Forms

Microdefinition (1)

  • Microdefinition = next critical business objective on the way to creating the whole product.
  • Everything must be checked against this

North Star Document (2, pg 136)

  • Explains the product in a way that can be visualised by the whole team and company
  • Problem it is solving
  • Proposed solution
  • Solution factors that matter for success
  • Outcomes the product will result in
  • Should evolve over time

References

  1. Coaching Agile Teams by Lyssa Adkins
  2. Escaping the Build Trap by Melissa Perri
Posted in Scrum Add-ons

Estimation

Posted on by beckycarter

Benefits of Estimation

Group Estimation Benefits (1, pg 105)

  • Research indicates group estimation is more accurate than individual estimation (Wisdom of Crowds by James Surowiecki)
  • Authority must be decentralised within the group
  • Anti-patterns = anchoring, analysis paralysis

Estimation Techniques

Product Backlog Estimation Techniques (1, pg 105)

  • Story Points (1,2,3,5,8,13)
  • T-shirt sizes (X-Small, Small, Medium, Large, X-Large)
  • Animals, fruits etc (grape, satsuma, lemon, orange, grapefruit, cantaloupe, watermelon)
  • ‘Same-size’ items (all PBIs are roughly the same size)
  • ‘Right size’ items (at least one item can be delivered in a Sprint)

Probabilistic Estimating (page 110, Mastering Professional Scrum)

  • Monte Carlo is an example of probabilistic estimating
  • Uses historical data with a statistical sampling method
  • Output is a range of possible future outcomes with a confidence level on that range
  • Embraces uncertainty of predicting the future

Estimation Caution

Asymmetric nature of software estimation errors (2, pg 203) 

‘ There are known knowns. There are things we know we know. We also know there are known unknowns. That is to say. We know there are some things we do not know. But there are also unknown unknowns. The ones we don’t know we don’t know’ 

Former Secretary of Defence Donal Rumsfield
  • Estimations are more likely to take longer than expected than they are to take a shorter amount of time than expected (i.e. they are asymmetric)
  • Developers estimate based on known knowns, and sometimes known unknowns. 
    • Some error comes from misunderstanding these 
    • Most comes from unknown unknowns
  • Larger tasks are more likely to have more unknown unknowns so the risk of rapidly increasing is much higher
  • Cone of uncertainty shows that the likeliness of under as over-estimation is symmetric 

References

  1. Mastering Professional Scrum by Stephanie Ockerman and Simon Reindl
  2. Lean Product Playbook by Dan Olsen