(upbeat music) - [Donna Benjamin] Stories transform us.
Stories connect us.
Stories make us human.
I'm going to talk about turning stories into websites. We've already heard some stories this morning. Our first three speakers Mark, Ellie and Tim. If you brand phrase there.
All talked about stories and our last couple of speakers conversations, we tell stories when we have conversations. And our last talk was probably a little more of the other half of my talk of putting stories into action. Lots of tips and tricks on how to do that.
So, thank you, I feel well kind of contexted. So I'm Donna Benjamin, I'm a project lead and business analyst at Catalyst IT and I've run my own business for 21 years.
Actually turned 21 last week, I thought that was kinda cool. Thank you, thank you there, thank you very nice. But that's me, hello! Who are you? Now, I've been sort of asked you to say who's a developer, who's a designer so I got a kind of good sense there. Hands up if you do agile.
Everybody, nearly everybody.
Hands up if you do user stories.
So, this is going to be pretty familiar.
So, you know just to you know refresh, what is a user story. It's gotta sort of familiar template and as a user I require so I can yeah? Nothing earth shattering here right? Here's an example, as a goat I want a purr programme.
Who can help me out so that the web gets done from multiple perspectives.
Thank you goat user stories for the excellent example. But, here's the question, where do user stories come from? Hands up if you sometimes feel like you're a victim of user stories.
(laughing) Not so many in this room, I gave the sort of a slightly different version of this talk at the Laravel conference a couple of weeks ago, nearly all developers, nearly all hands.
So where do user stories come from? Well, hands up if your user stories come from workshops. Bit fast.
Occasionally, not so many so I love workshops as a place to really connect with an organisation, the people in it sort of understand what's going on because you get to hear lots of voices at once. It can be a bit chaotic often brainstorming, it's very much at the sort of beginning of that double diamond that saw in Ben's talk. Um, hands up if your user stories come from interviews.
I'm seeing a few more hands come up there.
So, interviews are that opportunity to go one on one, to get deep, to do, to use one of my favourite techniques, which is the five why's.
So someone tells you they need something and you say why.
And they give you an answer and you just keep asking why.
Hands up if you are familiar with the five why's.
Most of you.
Surveys. Do you all use the stories that come out of survey data? Anyone? Very few, a few.
So, surveys are good to validate the information you may have got from other sources.
Uh, opportunity to get quantity of data, like how many of our users think this is a good idea.
To actually quantify stuff.
Also, great opportunity to create pretty graphs, which are going to impress some of these stakeholders. Competitive analysis.
Hands up if you use competitive analysis to kind of determine requirements.
Yes? So this is kind of desk bound research.
Some times its good to just survey the market, like, what else are other people doing? Compare and contrast.
Gather some numbers.
See what your sort of doing, huh? This is actually my favourite.
I'm in the agile world, right? Prototype and iterate.
Build it, tweak it, learn, experiment.
Perhaps your users, your clients, your organisation doesn't really know what it wants, you've got an idea.
But you build it, and try.
Prototype and iterate.
Whoops. Whoa. I'm moving on anyway.
Where have all of your stories come from? You've got some.
You've got these great user stories and now you need to invest in them.
Some of you might have heard of this acronym, BEFORE, it's why I'm going to bring the next few points. Our user story should be independent.
They should be whole and complete.
It can be built and worked on in any order. They shouldn't necessarily depend on each other. Good user stories should be negotiable.
They might be a starting point, but as you work together on it, you flesh it out, as you tell the stories about what the story is, things might need to change.
They should be negotiable.
They should be valuable.
You should be building something that matters. Where is the value? Who is getting value from this thing? Hopefully it is your customer.
Hopefully it's the people who are going to be using this product or website. Rather than necessarily some random internal requirement.
Is it valuable? It is estimable? We've got a story, can we get a sense of what it will take to build? It might not be an accurate to the second type of estimate of how long it's going to take, but do you have a sense of the effort that is going to be involved? The skills that are going to be required? And perhaps the time it is going to take.
Is it something you can do in a morning before lunch? Is it something you can do within a single sprint? It needs to be estimable, and if it's not, it's probably too big or too ill defined.
And small.
It needs to be a doable chunk of stuff.
If it's too big, if it's an elephant, you're probably not going to be able to achieve it within the constraints of the environment in which you are. And finally, it's testable.
Does it meet the requirements that we set out to achieve? Does it work? Is it good quality? Have we hit our acceptance criteria? Is it testable? Invest.
Independent.
Negotiable.
Valuable.
Estimable.
Small.
And Testable.
Whose heard of invest before today? A few of you. OK, good.
So the next one might be a few more people might be familiar with.
Smart. Whose heard of smart goals? Lots more of you, so we'll go more quickly here.
Specific I think while it generally refers to smart goals, I think you can also say you should have smart stories. They should be specific.
They should be measurable.
They should be achievable.
They should be relevant.
Timely.
Smart.
And then, my sort of third piece of this puzzle, when we invest in good stories.
Oh no, before that, if you haven't looked at this book and you want to know more about stories and go deep, this is a really good resource.
So a lot of my background radiation knowledge about user stories come from kind of dipping into this book.
I won't admit to having read it cover to cover en slavishly, but it's one of those books you can turn to and go, here's some good examples of why this matters. User Stories Applied by Mike Cohn.
The problem with user stories, though, is you can focus in on something very small and lose sight of the big picture. So how do you avoid that? Well, here's another good book.
Story Mapping by Jeff Patton.
This is a way of bringing your stories into a holistic whole.
And drawing back to the important things for your organisation.
Maybe it's your organisational objectives.
Or maybe it's some kind of key principals or values about your project.
But bringing your stories together and into a whole so they make sense.
So that when you zoom in on the small piece, you can also zoom out for the big picture.
Story mapping is a really good way of doing that. It also helps you prioritise things.
Sometimes you go, well, this doesn't fit in our big picture.
We can go, well, why are we doing it? And this comes to the actually how do we move our stories into building things? And I think, really, the answer is quite simple. We do it together.
We do it in teams.
Team work is how we turn our stories into websites, software, applications.
Team.
How do we turn a random group of humans into a team? How does that work? Whose heard of Tuckman's Theory of Group Dynamics? Not that many of you.
Forming, storming, norming, performing.
When you come together, you're forming.
And you go through a life cycle together.
When you get to work with the same team on different projects, you got a head start.
You already kind of know how to work together. But when you've got a new team each time, you've got to go through this process.
Being aware of that can resolve a lot of conflict just by knowing that's where you are.
You're in the storming phase.
You're figuring out how to work together.
That's in it's nature a kind of place of conflict. Sometimes we get personal when we're really just in a place where we're figuring out who's doing what and how.
It's really useful to kind of understand this. You don't need to understand this deeply, but just to kind of be aware that that's where you are in your sort of team work cycle.
So teams who work together well tell each other stories.
Now user stories grow beyond this kind of bland template requirement theme that is coming from somewhere Into that promise of conversation as has been said in the agile world.
That we actually tell the story to each other of why we are building this thing.
That we understand who this thing is for and why it matters to them and what it's going to allow them to achieve. Telling stories.
Together we can then realistically estimate the effort involved.
We've thought about our team, and our teamwork and our group dynamics, and whose skills and who can do what.
So and so can do X.
So and so can do Y.
It's much easier to estimate the effort involved in building any story when we have that sense of our team.
And why? Because we've got a shared understanding.
Telling the story, we understand the work.
Understanding our team and our group dynamics, we understand how we can do that work together. And where do we do it? And how do we do it? Welcome to the habitat.
Whose heard of cynefin? A few.
Cynefin is a Welsh word which means habitat by this guy called Dave Snowden.
And he sort of breaks down, you know, the world that we live in to this sort of four, five different areas. The obvious, or the simple.
In a story, in our sort of agily world, we can think about.
This is something I know how to build.
It's really simple.
I've done it before, perhaps I know exactly the steps.
It might still take a year, but I know exactly what's involved.
So it's not about the time, but it's about it's simplicity and it's obviousness. It might be a best practise and lots of people know how to do it.
You step up into the complicated.
Perhaps I don't know or I haven't done it, but someone else on my team does or someone on the team next door does.
It's complicated, but it's possible.
We know that there's a pattern out there that we can follow.
Or there's complex.
This is where it starts to get a bit more into we are going to have to innovate our way to solve this.
It's not clear. It's not obvious.
There isn't a well trodden path.
It's complex, but we can probably figure it out. Perhaps we do a bit of an experiment.
And then there's chaotic.
It's almost like all bets are off.
It's almost like you might have, um, an emergency responder team.
They know each other well.
They know each other's strengths.
But they are going into an environment where stuff is on fire and it's not about doing good careful processes, it's about savings lives and doing it quickly. And then you've got disorder.
And any of those other four states can tip into disorder with the right kind of impetus.
Perhaps a real earthquake.
Perhaps, um, a server down.
That's cynefin.
It's a really useful way of contextualising the stories you've been given or the stories that you've developed. You can think about what this story is and where it fits in your context using this framework.
Oh, dear, sorry.
So, given all that, what are we building? Well, we could be building a conference website. Or a media library API.
Or some some blockchain thing.
Let's go with a conference website.
It's something I know well and we're all at a conference so it's a context, a cynefin, that we've all got some familiarity with.
So let's start with personas.
Now we've had a few talks and we're all fairly familiar with the concept of persona? No? OK, let's do it the other way around.
Who has no idea what a persona is? (laughter) There's a lot less of you who say I have no idea. OK.
Look, this word does get used in different context in different ways and I'm going to probably break the rules that some of you are familiar with right now. But, as a potential delegate, all of you are delegates of a conference.
At some point in time, you were a potential delegate of this one.
I want to know the date of the conference so I can see if it suits my schedule this year, yeah? As a future speaker, I want to submit a talk proposal so I might be invited to speak at this conference. That worked quite well for me this year.
As a conference organiser, I need to review and evaluate talk proposals so we can curate the conference programme.
Yeah? Three pretty clear personas and we can translate them really quickly and easily into user roles.
Anonymous users for our delegates.
Authenticated users for our speakers.
And admin users for the organiser.
Now I come from the Drupel world, and Drupel 8 has these three roles just very conveniently built in by default. So I have an anon, an auth and an admin.
And I can assign various permissions.
So going from user story to website in that case is really easy.
Um, in general, it might be a bit more jiggery-pokery required and in laravel I might have to be quite sort of, um, deep and dirty in my data types to try to make that happen. But, there's a way.
We've got clarity about what we're building, so how do we break that down? In this case, I'm going to go with the conference website, um, as a speaker with an accepted talk I want to share my talk on social media so that people will come to see it.
So let's go a bit further down into that land of, here's another buzz word in the agile world, um, acceptance criteria.
Social platform logos should appear on every talk page. Okay, so, maybe we go with our competitive analysis world here and say what are some examples of that? Here's an old one, Lanyard rest in peace.
Um, share.
Clicking on each logo should pre-populate a post with the URL and session details.
Okay, kind of like this.
Is that what we we're talking about? Practising examples make it real.
When you get some kind of vague, fuzzy requirement, you can turn around and say, hey, have you got an example? How often are we really building something that is unique and never done before? If we were all doing that all the time, it would be wonderful, but the reality is we're often asked to repeat patterns.
So, again, back in my Drupel world, I've got a clear thing here, how am I going to do this? Um, maybe there's a package out there that will help me get this done quickly.
Get me to my minimum viable product as quickly as possible.
Do some research.
Do some competitive analysis.
This looks plausible, maybe this will work.
Let's have a look under the hood.
Okay, yep. Service links.
Service links.
So I can get there.
There's bits and pieces.
It's a well trodden path.
This is probably in, if we go back to cynefin, this is in the complicated, sorry, in the obvious or simple.
It's going to be fairly easy to do this.
So, the agile manifesto.
Who knows this stuff by heart? Individuals and interactions are the processes and tools.
Working software and the comprehensive documentation. Customer collaboration over contract negotiation. And responding to change over following a plan. And it's not to say those things are not important on the bottom.
It's just that we value the things on the top more.
I kind of one day in a moment of, kind of, crazy sort of novel gazing, came up with these fours words to kind of conceptualise the agile manifesto for myself.
People collaborate, product evolves.
When we work together, when we understand each other, when we can tell each other stories, when we can understand the value involved in those stories, we get to build something awesome.
And we get to feel good about it because we can rely on each other when we do it together. Lots of references Thank you.
(electronic music)
