Posts

Showing posts with the label user stories

Using JTBD in a B2B setting

Image
It's now about 4 years since I started to think that the "As a ..." user story format wasn't the best starting point for building long running products. One of the things that I found and liked was the jobs story format . The situation When collecting the data I didn't do proper JTBD interviews as such. But I did extract the info from pre-sales calls, product demos, and talking to users. Plus enriching the collected date with the known strategic goals 15below as motivation , i.e. reduce support overhead. I have adapted it a bit and marked it up for our dev teams here. But here is an example for a password reset function. Main thing is that as a B2B supplier we have four distinct groups that could appear in the stories. 15below (us as supplier) as an org,  our clients, their users,  and the client's customers  Here is a simple example for a password reset function all the words in bold are entities that have a defined meaning in a glossary, ...

BOOK REVIEW: Fifty quick ideas to improve your user stories by Gojko Adzic and David Evans

BOOK REVIEW: Fifty quick ideas to improve your user stories by Gojko Adzic and David Evans It has taken a while since my last book review to get the time to do much reading with moving. But here is my round up of "Fifty quick ideas to improve your user stories" by Gojko Adzic and David Evans Formats : Paperback, ePub, Mobi, PDF Where can I get it? From Leanpub , Amazon or any good bookshop.   Who is it for? Anyone involved in a software development project working in an iterative manner. As long as they understand some of the basics around user stories, e.g. they know what INVEST stands for. What's it about? As the title suggests "how to improve user stories", but it is a bit more than that. It covers the whole process including planning and iterative delivery activities. What's the book like? Each double page spread follows a similar style starting with an introduction to a new tip. Often illustrated with an anecdote fro...

On storytelling and stories

Image
Stories & Storytelling_1956 by Sterling College (flickr) In a lot of software projects the tools - such as prioritisation, backlog grooming, MVP - and artefacts that they produce - such as  job stories, roadmaps, personas -  are useful but ultimately I believe that they are about allowing a community of people to tell a story.  When "going up" to people at budget sign off level they are generally short of time, so the stories need to be the point and tightly foccused on giving a sense of what has happened and what will happened, including topics such as: What are you doing?  Which business goal does this achieve?  What is the value? (e.g. either cost saving/revenue protection or increase in revenue) In my experience  when going into detail level with implementers  they like to hear the answers to these questions:  Why is it needed?  How does this fit into bigger picture? and What will we be doing next? I have tried exp...

On buying behaviours and usability

Image
This week I have been purchasing the photos from the running events that I've taken part in this year. One thing that I like, about getting several sets at the same time, is that it allows me to look at the user experience I come away with from each photo solution. So here I'm going to briefly compare two sites and think about any lessons I could draw for the travel industry, since that's where I work. The first experience I just wanted to discuss two different sites that left me quite different feelings. The first looked like a user forum from about 10 years ago. The search on race number takes you to page dominated by the search tool and other screen furniture about the gallery. This is followed by thumbnails of the matching photos. Clicking on any of these photos then takes you to the screen below, with various purchasing options including confusingly "All my images". There are some Google ads, which when looking at a friends images had an amusing...

On empathy and solutions

Image
Recently I've been thinking about e mpathy in product development and how often in commercial software development that you are not the user. One area that I see a lot of people focus on is separating the problem from a potential solution in requirements.  Empathy Map by Oliver Quinlan User stories especially attempt to do this, unfortunately I don't think that the "As a ..." format as practiced is helpful, from my experience it's too easy to make it a justification exercise for a solution, it doesn't really help promote empathy or show that the user has really been taken into account. (Your mileage may vary and I'd be interested to hear from anyone who thinks that the "As A ..." user story format is the best available) In Innovation is not magic   Aly and Fernanda make the point "Innovators can get excited about things they can do and can become dazzled by the splendor of  their own creation. When someone has an idea,...

On research and application

I am currently lucky enough to be working on a project where the developers are looking into what they can learn from academic computer science and spiking various options to explore the solution space. This got me thinking to how relatively rarely you see this, in my experience programmers tend not to read industrial journals in the same way that say civil or electrical engineers might.  One thing that I would expect to see more in agile literature are Grice's conversational maxims (Grice 1975) Maxim of Quantity: Make your contribution as informative as is required for the current purposes of the exchange. Do not make your contribution more informative than is required. Maxim of Quality: Do not say what you believe to be false. Do not say that for which you lack adequate evidence. Maxim of Relation: Be relevant. Maxim of Manner: Avoid obscurity of expression. Avoid ambiguity. Be brief (avoid unnecessary prolixity). Be orderly. For me the...

On impact and behaviour

Something a bit different, some thoughts on impact mapping and a workshop that I was recently lucky enough to attend. One of the first product owner survival camps run by Gojko Adzic with Dave Evans. The workshop description starts with ... So you're a product owner with an agile team? Congratulations, you are the winner of the world record for the worst named, worst understood and most confusing role in software delivery. Apart from the fact that the PO almost never actually owns the product, they are pushed into an unrewarding role that is mostly about managing "someone else's problem". That certainly rang true for me ;) how can you take a backlog of items that you are positive that you need right now and prioritise for small, sane iterations. Further, how do you avoid WaterScrumFall in this world? The answer presented here was around impact mapping and expressing things in terms of business goal and how much the "customer" was willing to invest in t...