Episode 48: Agile Practices: Backlog

Hello, and welcome to the bottom up skills podcast I might pass since I'm the CEO at QualityNet. And today we're in the fourth, last chapter of our enormous agile software development. Series here on the bottom up skills podcast. And today's topic is the backlog. Now this little old thing kind of matters.

Yeah. In an agile project. Um, a backlog is the, really the foundation of what everybody comes back to, to work out some important things. Uh, number one what's most, it was important in terms of the work that we are. Making right now could be design development. Wireframes user stories. This is really the essential piece, the [00:01:00] backlog, and as each individual in the team should know what.

They are working on right now and the backlog is the source of this. So what we're going to do is we're going to talk a little bit about the backlog and we're going to discuss how to get the right stuff in there, how to get the right details in there. And ironically, although a lot of people focus on the backlog for their current sprint, really.

The best practice with a backlog is to be actually looking at it, uh, in terms of what's after the sprint you're working in. So looking ahead and, and really this idea of being at least one or two steps ahead. So we're going to get into all of that as we talk about some of the best practices in agile and scrum.

All right. So there's little old backlog now. Um, if you're trying to visualize what this might look like, it's, it's simply just a list of work [00:02:00] of the key pieces of a product. And if you've been listening to this series, you'll obviously know that we're quite fond of JIRA and confluence at Colton. So you might want to check out those products.

Uh, designed and developed by a fabulous Australian company too. I might add. And, um, it's there that you'll be able to manage your product backlog and, um, I want you to, um, visualize a very rich task or that's ranked in order of priority. That's really, uh, At its simplest form. That's what it is. But if the right attention and the right effort is put into each and every one of these, so user stories, epics, and themes, then this is a really powerful tool because a whole bunch of cool things happen.

First of all, if you use a product like JIRA, you'll actually see from [00:03:00] sprint to sprint how good you are at getting those two dues done. And it gives you this information that will help you judge better. How to predict your time for subsequent sprints as well. So, you know, the, the key thing. When you think about your backlog is this list must be not only managed by your scrum master.

Everyone must be contributing because then the data is rich, then it's relevant. It's got context and it helps you when you've got a question, uh, about something in the backlog, then the requirements and the attachments and the rich data. It is listed inside of it. Can tell that story. I think a really good, uh, check.

For a backlog is if the backlog has been a bit neglected, the node of write-ups inside each of the user stories or each of the issues, um, you're going to [00:04:00] actually find that the information is not enough. And then the worst thing in the world happens. You have to send an email, you have to like get someone on text or give them a call and say, Hey.

You say that we have to do this right now, but there's not enough information, so I'm not able to meet. So if you have a backlog, I put time and effort and attention. Towards it, and it will serve you very well because everyone will know what matters. What's the biggest priorities right now. And here's the critical thing that we'll know what they're meant to be doing now.

And that means less clarification conversations about who's doing what. So as we talking about clog, uh, I'm just thinking about all of the things that I've seen in projects. And I think if I reflect on, uh, the three best pieces of advice that I can give to you about using a backlog, it's the following three, I think you [00:05:00] need to groom it.

I think you need to, uh, have high attention to the details. And I think you need to be planning already, at least one, if not two or three sprints ahead. So I'm going to dig into each of those now, but grooming devil in the details and working several sprints ahead. This is at the essence of the best practices of using a backlog in an agile software development project.

Alright, grooming. You know, for me, this is really interesting. We're not talking about going to the barbers. We're actually talking about software here, but what we need to do is get together and to really remind ourselves of what is really important for this product now. What's really, uh, fascinating here is how often teams find themselves working on things that are not the highest priority and in an [00:06:00] agile software development project.

The thing that matters the most is a working product. And the thing that matters the most within that is the essential. Feature Epic theme or user story, whatever the killer app is in your product. You start there, you don't start with the login. You don't start with privacy and disclaimer, you don't start that any of those, cause they're really straightforward.

It's all about knowing what is number one on your priority list. And that's what the grooming sessions should do. You should be getting together as a team and collaboratively talking about and evaluating together. What's essential in this product and therefore organizing the backlog, all the issues in the backlog, you organize them accordingly.

So pay attention to make sure that you are focused on grooming towards working code. And secondly, making sure that it's the essential features that are working, you know, [00:07:00] as I said, you know, logging in and all those secondary pages FAQ. Those things are not tricky. Focus on the complex things that add the most value.

And that's a great way to start grooming your backlog. Now, the next thing that I mentioned is details and, uh, When you start you're, you're, you're going to add a bunch of, uh, issues and user stories and epics and themes and all that good stuff into something like JIRA. And there'll be a bunch of write-ups and something like confluence, which will give a broader, uh, more Wiki or Google docs kind of context behind what's in the backlog.

But. The really important thing here is make sure that the issues inside of the backlog, these are the individual items that make up the backlog, make sure they're written written up. Well, I mean the classic thing not to do is just to have the heading a [00:08:00] title of the issue and then you open it up and it's blank inside.

That's no use to anyone. So take time to make sure that the requirements are written up that may be attaching or linking. Relevant documentation. And I, and I said this earlier in the show, just make sure that a third person who came to this, let's say it's something for a developer that they could read this issue or user story.

And there is sufficient information for them to actually begin their work. If it's insufficient. You'll know because they have to call you and say, Hey, I don't understand. Where are those things that you mentioned? Uh, I don't understand why I would do it like that. And then that is the classic moment where, you know, the issue is not written up completely.

So make sure you take the time to put the detail into it. On the bigger projects you might find a business analyst writes this on really big projects. The business analyst and the product [00:09:00] owner will be. Always, always reviewing, editing, adding, and revising their...

047 Agile Team

[00:00:00] Hello and welcome to the bottom Mount skills podcast. I might pass since I'm the CEO of quality science and we are at the last part of the people in teams, chapter of agile software development. And in this episode, we're going to talk about the development team. And previously we've talked about scrum master and the product owner.

Now we're going to talk about the team. This is the mighty engine. Of all that great work that's going to happen in your brand new software or digital product. And I think what is most important when you think about asking the question, what is a good agile team? There is really only one answer and that is that teams should be multi disciplined multidisciplined that they should come in.

It should [00:01:00] be like the 18, you know, it should be a cast of characters, springing different skills so that you can have a really diverse point of view. And that will help you really come up with some really innovative approach approaches to some simple problems or tackling the big overall pains and gains of your users.

Now as diverse as they might be in skills, what will bring them all together as a shared vision and commitment to the project. And, um, that's really essential when you have a multi discipline team, all gotta be excited, motivated. Fired up about the vision of what you're going to build committed to the project.

So let's uncover how you can span everything from deep work to collaboration in an agile team. Setting. All right. So yeah, let's talk about this team. Um, what's in the team [00:02:00] and like, what does multidisciplined look like? And, you know, the thing, when I think about all the different projects, um, an agile team is, can be anything from hardcore, uh, engineering.

Design, um, user experience. Um, I tell you what great BAS business analysts, uh, dev ops copywriting design and art delivery members. Um, I mean, Oh my gosh, there are so many different roles that can be inside different skills that could be, uh, in. This team and you could call upon experts. So let's say you're building a product, that's all about workouts.

So you get health and fitness [00:03:00] experts. You get physiotherapists, nutritionalists you name it, bring all of those people together. Now the trick in bringing them all together is to have this really come and go. So. You need, do need to make sure that they're actually excited around the idea of the product.

Like hello. Like it doesn't matter whether or not in the case of creating like a workout app, whether they're workout boffins, but if they're genuinely interested and compelled by the notion of Lexmark, let's make people more healthy fit and, well, that's really important because without a doubt, yes, we will go to what we call.

The Valley of darkness. And that is where you're not sure what you're going to build. The timeline's creeping up. Everyone's for real King out. And it's. This bond around a common goal that will kind of bring you altogether. [00:04:00] So I think that, you know, you need to make sure that, you know, whilst you bring that diverse cast of characters together, you have to ensure there's a common goal.

Now, some of the other really important things is. You got to communicate like crazy. And at the start of that is sharing what you're working on. Not only in the daily scrums, but making sure that people in other disciplines really have a sense of what you're doing and what you're contributing. And on the other side of that, I think as a receiver of these messages, you have to be genuinely interested in the work that others are doing.

Because if you understand the various disciplines that are contributing. To one single product. I think you're in a better place to integrate them, to bring, uh, the whole product together. So that is elegant, seamless, and just insanely intuitive rather than being really [00:05:00] clunky. And obviously, you know, A force fit between all those things.

So there's a bunch of things going on. There's this cast of characters fired up about a goal. They're all connecting and working in a similar way. And I wanted to take a moment to. Reflect on two ideas that I think drawing Mave the performance of a team. Now, if you are interested in, um, how agile teams work, uh, both in a detailed view and on a kind of a metal level, you should jump over to bottom up.io, where you can check out the full masterclass that we have.

It's it's all free. Well, you can sign up and, um, go really deep on some of these topics. But for this episode of the podcast, I really just want to share with you two ideas is around, uh, an agile development team and the people that build the product. Okay. First [00:06:00] idea. It's all about finding balance and this it's really common sense and it sounds really easy.

Yeah. When you talk about you, you know, how you think about your time, but finding the balance is actually really hard in a fast moving agile project. And this balance that I'm talking about, let's say you're a team member in an agile project. The balance that I'm talking about is between doing your deep work.

Your expert work either individually on a very small team and then your collaborative work, where you're often doing work sessions with other people from other disciplines in the project. And this harmony between deep work and collaborative work indicates. So much of whether a team is going to build a great product, because sometimes you see, let's say the archetypical [00:07:00] developer who doesn't really want to work with anybody else because they're too busy writing the code.

So they're just maxing out on deep work, but they might be spending time thinking about problems that if they maybe went and found a BA a UX or UI designer, uh, maybe even a dev ops person, Maybe just sharing the problem might half of the problem. Um, so sometimes there's a tendency to do a deep work and that makes it very challenging because you really do have the team operating as all these really small silos.

On the other hand. Sometimes there's just too many work sessions, too many meetings. There's no time for the work. So when I talk about the success of an agile team finding balance between deep work and collaborative work is. It is so important because if you can go do some deep work and then you bring it back to your colleagues, you jam [00:08:00] on it, you discuss it, get some feedback.

You go back, do some deep work, come back again from another working session. If you can build that, that cadence you'll find that you just fly, but there's an under 10 unintended consequence to the balance. Here is not only is your deep work thoughtful. But your collaborative work gives all the other team members a really good sense of what you're working on.

So it means their work will fit better with yours. So that's the first thing, finding the balance. It's a really fundamental challenge to a good team. So make sure you strive for finding that balance between deep and collaborative work and the last thought I have for you. Is to connect. And I mean, this from a point of view of be connected, um, during [00:09:00] the day, uh, be connected for your demos, for your retrospectives or common practices in an agile project, you should be doing your standups daily.

Um, but the other thing is you really need to make sure. That you are all talking the same language and let's say I'm working on. A feature and I give it a particular name, which has certain assumptions, certain user stories attached to it. If I'm not constantly connecting with others, like if I'm the designer, I need to talk to the developers.

And if I go too off on a tangent and I created a let's call it the headquarters a feature, and they're all cal...

046 Agile Scrum Master 

[00:00:00] Hello, and welcome to the bottom up skills podcast. I mike parsons I'm the CEO of quality assurance, and we continue how dive into agile and in particular, all the people and teams and good stuff that an agile project requires. And today we're talking about the scrum master, and this is the second role that we're really examining in the.

Previous episode, we did talk a lot about the product owner, and I think it's safe to say that the scrum master is the right hand person to the product owner. So I want you to think of this role of the scrum master in an agile software project is a bit like the orchestrator. You know, standing in front of all the different media  who on their own couldn't really, uh, make a [00:01:00] great song, but together they can.

And the scrum master's job is all about being flexible. And adaptive on the crazy adventures of building a brand new product. So in this episode of the podcast, we're going to dive into the world of charting, this course, uh, chatting the course of each sprint and how the scrum master removes blockers. So the team can thrive.

Sounds pretty good. Right. And if you're really interested in sort of the people in team side of agile or. Agile. It's a whole, as a set of principles and scrum, you can jump over to bottom up.io, where we've got a free master class and you can jump in there, uh, downloaded or get the deck. And we go really deep on this, but let's for now continue our dive into this world of the scrum master.

And, uh, Sutherland the author of the book, scrum, [00:02:00] uh, really framed the role of scrum master really well. Uh, in his book, a scrum, he says the scrub master. The person in charge of running the process, ask each team member three questions. What did you do yesterday to help the team finish the sprint? So that's number one.

What will you do today to help the team finish the sprint? That's number two. And number three is what obstacles are getting in your way. And that's it. That's the whole meaning every day that the scrum master has with the team and really it's at the essence of their role, everything starts with those questions.

How are you doing on this sprint? What are you hoping to do today? And what's in your way, what are your blockers? And what's really interesting is you can do that on a project or what we do quality assurance. When we run our teams beyond a project, say a [00:03:00] marketing team or sales team and ops team. Well, like what are your goals for this week?

I E the sprint and what are the blockers that you're experiencing? And it's such an efficient way to frame how you're going to work. I think it helps us work faster and work smarter, but let's get back to the scrum master this break down this role, because it's so important because what the scrum master does is the scrum master creates transparency in the project.

And in particular in the sprint. So usually two to four weeks, probably closer to two. And that transparency is like, what are we working on? And what's next, it's complete. Um, they really bring, um, uh, timely reminder to scrum values, uh, about focusing on working, uh, Product working code and really protecting the team from too [00:04:00] many variations, removing blockers, and really being the centerpiece, um, to the daily operations of a project.

And, uh, in traditional terms, if you had been a project manager or project coordinator, The scrum master is a agile and scrums answer to that same, to that same role and a great scrum master. We'll have the ability to, to organize. And I mean, this is really important, um, to see how to break down the difference between themes and epics and user stories, to understand the tools and resources and the people that are required.

It's a fascinating. Executional hands on kind of role. So if you're. Really somebody who thrives in the opportunity to get things organized and all right. I [00:05:00] think that think of people who love putting labels on things or who love organizing bookshelves, you know, people who, when you look on the server on, on your, say your Google drive, they have really well organized folders are, and that's always a great indicator of a scrum master, but I think it's more than just organization.

I think because in an agile project we're continually adapting and refining and iterating. This idea of being flexible is essential because if you're too kind of stuck in your way, which would be a very classic project management office waterfall kind of thing, uh, you're going to really struggle in an agile project because it's so iterative.

Um, and one of the key things. You'll have to consider on an agile project is really weighing out highly, uh, you know, technical or highly interpretive things such as [00:06:00] creativity, design, that sort of thing with all sorts of logic about. Time allocation of resources and so forth. So the ability to span those two worlds is really, really critical.

And as all ways, uh, as you'll hear me, you talk about a ton on bottom up skills is communication is at the heart of this. If every day the team is not connected. Through the scrum masters facilitation things can go off track real quick. So as all of these things are spinning around you, the technology, the design, the stakeholders, and all of that communication.

I think that the form of leadership that the scrum master brings is insane. Calmness. Calm under pressure and sticking to the plan because this is really, really essential. If you've got a plan for the sprint, [00:07:00] don't allow forces to come in and rock the boat. Keep everybody. You know, sometimes you just have to remind people of why we're doing it, right?

These user stories, these epics, these themes in this sprint and not others. And that's, that's a sort of, it's almost a form of protection. I'd be yeah. Teflon, coating around the team so that they can be autonomous. They can focus on the work. So let's talk about the work of a scrum Mazda. Now we've talked about, you know, managing daily standups and scrums.

We've talked about all of the communication and the resource planning, making sure that user stories are planned well in the backlog. I want to find what I think a complete. Sort of Ninja like scrum master looks like, and when I've seen and worked with great scrum masters, sort of three [00:08:00] things that they, they do, which make them.

The cream of the crop. The first one is that they, they really get into the planning of the sprint and they get the teams buying contributions to what's in, in terms of the user stories. And I think that they are constantly aware of what must be in the product and what is nice to have and having that ability to plan the sprint like that.

Creates enormous comfort for all the team members, but real clarity. So people are not, you know, weighing up ambiguous or challenging, um, topics. There's a lot of clarity about what we must have. So planning the sprint is the first one. The second one is creating a rhythm now. What's really important is when you bring all these talented people pulled together, you've got to kind of create, um, a sense [00:09:00] of harmony, rhythm and momentum.

And it can take a little while to get going. And if you're a scrum master, there's all sorts of things you can do. And here's what I see. Great scrum masters do. Number one is they catered at individual work styles. Me, for example. I do my best and deep work in the mornings. So I hate, hate, uh, sync up meetings, scrums, uh, stand ups in the morning that interrupt my quality time.

That's just me personally, but a great scrum master will kind of try and adapt and worked around the individual work styles. Uh, you know, I'm working with...

Hello, and welcome to the bottom up skills podcast I might pass in is I'm the CEO of quality plans. And we are taking a new turn, a new chapter in our agile software development series. We are going to the heart of things, the most important episode. Our agile software development series. And we are going to talk about the key role, the role that defines more of the success, the direction, the momentum of an agile software product project.

And that role is the product owner. So this idea of somebody. That truly owns the product. They are the beating heart. They are the central force of an agile project. And I can tell you that it's not a role for the faint heart. It is complex. It is. Big stakes, because as you're pulling a lot of different things together, and I want to talk about how they think what they have to weigh up and some of the key activities that they do within a project.
And I will say this, that if you are. In the world of software and technology and design. If you are interested in, um, a career in the world of technology and product design, there is no more important role than the product owner. And these are the most scarce. People ever, because it is a little, a little bit left brain, right.

Brain. And it requires quite a bit of experience and it is. It's intense. Um, and so this is why they're scarce, rarely cited in the wilderness. They are product owner, and that's why it's so important that I share with you. This thinking to hopefully inspire you, inform you. Maybe you can become a product owner, or if you are one.
I hope that this only goes to confirm to you not only the key value that you create, but maybe gives you a refund on the importance of the role. Okay. So we will do some other roles as well in this series. So make sure you stay June for the next episode, but the product owner is the backbone. But we've also got people like the scrum master.
We have different team members. We actually have a whole range of stakeholders that are involved, but all of them, all of them, a guided by inspired, by supported by. The product owner, because the product owner is somebody at their heart who is the mini CEO of the product. They are the true leader of the product.
And as any good servant leader would be, they are open. Uh, they are unbiased and they take on board the contributions of everybody in the team in order to get the very best product and to make the best decisions now, um, what is essential is that there's sort of an unspoken thing about product owners.
And I think this idea of them becoming the driving force. Of the product. And what I mean by that is there are going to be moments, which I call the Valley of darkness, where there's a lot of uncertainty in the project and everyone's like, Oh my gosh, it's complex. We don't have much time. We don't know exactly what we're trying to do.

The things we thought we'd do. And it working. This is going to happen and it will happen even more if you're building a first-generation product and it will happen more. If you're trying to do something that's ambitious, you really trying to shift the needle. So. Make sure that product owners, whether you're a product owner or you're recruiting product owners, that they are people who take extreme ownership, extreme ownership that is inclusive, not that is charging off into the wilderness and leaving everyone behind, but truly brings.
People together. Now I want to talk about the kind of three key things, activities that the product owner does. So we're kind of told a little bit about their mindset and behaviors. Let's talk about like the things that they actually do. The first one is managing the backlog. The backlog is the work to be done today this week, this sprint, and it is.

Constantly changing and being reprioritized and is the product owner who makes the final call there. So managing the backlog job, number one, job. Number two, very related to this is working out what is going to be in which release of, uh, The product or what we're doing in sprint one versus sprint two and looking at the overall roadmap that we're going on, whether it's two MVP, Bita V one V two V three.
In one, two months, one, two years, this idea of release management and making the call about what's in and what's out, what's serving the greater good. So that's the thing, big thing, release management. And the third one is stakeholder management because in an agile project, you can have a lot of different stakeholders.
Everything from exec sponsors, uh, expert contributors, um, brains trust, um, direct product owner, project owner. Uh, you could have business analysts, design, thinkers, user interface, designers, Java developers, dev ops, you name it. They could all be in there and they all spin around the product owner. The product owner, they are the guiding light for the rest of the team.
So it's really important. It's a pivotal role. And if you're excited about it, I really do encourage you to research Google a way around the role of a product owner, because they're incredibly hard to find they take a long time to cultivate and they're very rigid. And so a lot of companies, they product owners and just simply can't get them.
Now, um, I just want to finish by looking at the main. Thinking the critical thinking, the first principles by which this product owner is working and it's really the harmony let's, let's look at, uh, things you've seen in, in the product team and in the business on a day to day basis, there is a balancing act and it could be between what your UX expert is telling you and your tech experts telling you, and as well, the business owner.

And so the, the, the product owner is the intersection of that conversation. They're the conduit, the balancing act, and the decider said differently. They are balancing between user needs, business requirements and technical constraints. Or we, if we want to take this a level higher, they are weighing up is what we're building desirable for users.
Feasible through technology or viable for the business. And as I elevate it, what you will begin to sense is that the product owner has one of the most exciting roles because they get to play in these three distinct areas. And on the flip side, the greatest challenge is you have to play in those three areas, and this is not easy.
So. This is why you have to have this paradigm. Really clear in your mind, you have to have the right sort of behaviors in order to do it because everything comes to the product owner. Sometimes teams tend to have their, a business analyst is the product owner. Sometimes the UX person, sometimes one of the developers, what I've actually found that if it is a big.
To medium sized project that the product is I own a row is a dedicated role outside of those other key contributor roles. It is a standalone role. So. If you want a North star around how to build your career, I'd say if you love product and you love being in those worlds, head for a product owner, if you are a product owner, please know this is such a tough job to weigh up left and right brain things to weigh up a technical constraint versus does this really add up for the business and Hey.

Are we building something that uses love, but I will tell you this one thing that if you, if you can really adopt this paradigm and help with managing the backlog and stakeholders and the release management, you'll truly be. An absolute huge contributor to your organization. You'll create a ton of value.
You'll help us go out into the work and build products that are really worth building products that really solve a problem. So they go, that's the first crucial role in a agile scrum team. I'm going to take you through a whole bunch of them in subsequent episodes of the show, but I hope you've enjoyed delving into the key role, the product owner in agile and scrum teams.
So that's it for the botto...

Hello, and welcome to the bottom map skills podcast on my passings CEO of and
we are getting into the tools of agile software development. Now, quick note here. Not getting
into the actual coding tools, but we're actually getting into the tools by which we can manage
projects in an agile way. And I'm very excited to introduce two tools to you today.
They're called JIRA. And confluence, and I'm particularly excited about sharing those because
they are made by my compatriot Australian friends. So what fantastic software it is, and I'll do
my good, proud Australian. Um, Tip of the hat to the team at Atlassian, you make JIRA and
[00:01:00] confluence. So, um, why, why is JIRA and confluence so important?

And why have I selected it as the key in terms of tools to managing agile software development
projects? Well, I have to say that when you are doing an agile project, I think the most important
thing to realize is intense. It's fast. Um, you've got a clear direction that you have to go. You
have to move fast.
It's a small team and there's this high degree of ownership that's required. And I think also what
you have to realize is that agile is a. Is an idea. And particularly if you're using scrum as your
method to do agile, where you have to trust in the process, and you've got to trust in the process
because unlike waterfall agile says, Hey, look at the [00:02:00] start of the project.
We don't know everything. So if we have a good process, we know in the end, we'll answer all
the questions that we're going to have. And so at the heart of that, there are kind of two big jobs
to be done by the individuals in an agile team. One, they have to collaborate, they have to work
on stuff together.

And two, it's all about managing your tasks, your contributions in your role. And later on in this
webcast, um, in this podcast series, we're going to talk about all the different roles, but there's
these two jobs, collaboration and tasks and tasks obviously kind of live in a greater workflow.
Now, if you're going to trust in the process of agile and scrum and you want to collaborate and
you want to get your tasks done, then confluence and JIRA.
Uh, the essential tools. Now, if you're a little bit more advanced, [00:03:00] you could be
adopting some additional, uh, tools you could be, um, uh, pulling together some, some ad-ons,
uh, here, but for the vast majority of people, you will find that confluence is graded, helping you
collaborate on your thinking in your ideas.
And JIRA is just great at prioritizing tasks and the work to be done. Now, the great beauty is
they work Batman and Robin because they're made by the same company. So if you want to
work in an agile way, if you want to deploy scrum, you go to kick open an instance of confluence
in JIRA. And what I want to do now is take you on a quick tour through the roles that they play
and why, why they're important.

So let's start with confluence. Um, the best way to think about confluence is it's almost like
Google docs meets a Wiki and it's specific [00:04:00] obviously for your project. And I like
confluence because it's a great way to edit your work, um, and to capture your thinking. And I
think it's really essential that uses.
Uh, that collaborate is in a project can work no matter where they are, they can accomplish
more together by, um, bringing the thinking together. A great example of this is, um, let's say
that we've got an idea for a certain feature. That idea has to be documented. It has to be tested
and validated and brought to life.

And you know, the thing is that, um, You will be amazed at how important it is to be able to look
back somewhere and find out why are we building this feature? How do we get to it? And what's
all the related information to it. It sounds a bit abstract [00:05:00] now, but when you're in a
process object, if you have this in a centralized place where everybody can understand.
What we've decided to do and why you can get on with more of the design and the
developments. You can see people's comments. Um, you can see the kind of story behind what
you're doing, and this alignment means that you can then focus more on doing great design,
great code and bringing things together. If you don't have this.

In a central place. What happens is you end up finding yourself, having all these calls and
meetings because people are, we're really on the same page and that's what conflict, souls.
And what's so fun is that putting the thinking behind a user story feature and Epic, a theme,
right? All that a backstory can then elegantly fit into this other tool.
[00:06:00] JIRA. And what JIRA does for you is at its heart. It is all about getting work, done the

task itself. And you know, the thing is we can have great task management for ourselves, but
here's the thing. How do others know what you're working on? And if they don't know what
you're working on, What has to happen is everybody has to have more calls and more
meetings.
Are you working on that? What, what are you working on right now? What's up for review.
What's complete. What's in your next to do list. If you don't have your, uh, tasks and workflow
centralized, then you end up spending all this time, just updating and synchronizing between
team members. And so what JIRA does a great job of doing is getting every member of the
team on the same [00:07:00] page as to what we're doing now.

What's next, what stuff is finished and ready for review and what stuff has been reviewed,
tested, validated, and can be marked as complete. So this planning and tracking of our workflow
is an essential part of an agile team because they move so fast. Particularly now most teams
are virtual and remote.
It's essential because if it wasn't there, you'd be wasting all that time. Like I talked about. So
these are two tools that are absolutely essential. So you have the backstory in confluence, you
have the dues, you have the activities, the tasks, um, stacked up in JIRA. Now in JIRA. What
we generally do is organize this as a backlog.
And we put this backlog of activities into a sprint, and this helps us track what we're doing. It
sees the general productivity of the team, and it brings all of the, [00:08:00] where the hell are
we into one single place. Now I just want to spend a quick moment to outline the key things. But
if you're working in this agile scrum way, particularly when you're organizing things in JIRA,
you're going to talk about four concepts around the work.
The smallest, most practical thing is a user story. And that's a requirement down to the pixel
down to the click of what's going to happen. In a screen in a moment of interaction for the user
that then gets bundled up into epics, which tend to be a little bit more, um, uh, common, bigger
feature sets rather than specific little interactions.

You then have an initiatives, um, bucket. I don't use those a lot, but the big one, uh, that I
certainly use is themes. These are, if you've got a product, um, a product might be built of, uh,
five, six themes. 2030 epics and [00:09:00] hundreds and hundreds and hundreds of users. This
architecture theme initiative, Epic story.
Is absolutely the currency, the vocabulary, the language of scrum and agile when you're using
these tools. And you really gotta spend some time getting into, into that. You can, um, obviously
if you are really interested in that kind of thing, jump over to bottom up.io, because we do a big
breakdown in our agile masterclass.

And you can learn a lot more about it, but this really is the key thing. And if there was one last
thought to leave you with the absolute conversation every day, every hour is where are we with
th...

Hello, and welcome to the bottom up skills podcast. I might pass things. I'm the C E
O of quality wins and we are rocking along. We are in the next episode of our agile software
development series. And this time we're going to get into the different types and flavors of agile.
Now in the previous step episode, we really dug into some of the high level.
You know, a primary thinking behind agile, which is around values and principles and how it's all
about being small, focusing on writing the code, doing the design and going fast. And. Whilst
these values and these principles. So this really well in understanding not only how to design
teams, but I would say you can design companies [00:01:00] around this whole idea.

Once you get into the practice of agile, what's quite remarkable is there's millions and millions of
permutations and variations of agile. And this is where sometimes people get confused. And this
is where unlike design thinking, which has a clear kind of universal path math pioneered by the
Stanford D school.
In this case, this is a much bigger practice, much more commonly used. Um, it has, um, You
know, a history of being related to not only lean, but manufacturing processes in the fifties, in
the sixties. And as a result of this, that we actually see this huge variance, these massive
portfolios of different types of way to do agile.

So I want to take you through a journey through some of those explaining. Uh, just the, the
general difference between these [00:02:00] so that you can start to orientate yourself around it.
What I'm also going to do is really call out probably the two primary flavors of agile software
development that you'll either have heard of.
You might know, or you will run into if you're working in the world of technology. So now we're
going to go. Into the practice, the practice of agile and the crazy thing is that you could easily
count beyond 40 different methodologies. These are ways to practice agile and they all have
different sorts of names.
Now we're going to look at these and I obviously, you know, I wish I could take you through
them all. Um, In fact, I wish I even understood them all because there's so many, but I'm going
to give you a general sense of how they work. [00:03:00] And then what we're going to do is
focus on two particular flavors, which is scrum and Kanban.

And so we'll go into those. But first, before we get to those, I want to kind of paint you a picture
of, uh, the, um, These different areas in the world, world of agile. Now the first one is one that
you might have heard, um, that was employed at Zappos. Um, a really famous pioneering
company. They do a lot of stuff in a radically different way, and they've actually, uh, taken a
flavor of agile.
You know, which has its hallmarks and origin in this idea of, you know, self organizing small
teams. And they took that. To an extreme, and that's what we call Holacracy. And Holacracy is a
form of decentralized management and [00:04:00] organizational governments. So this means.
It's quite, uh, it's, it's very similar to what we call radical management.
Um, it's related to theory of constraints, um, management 3.0, but what you have to imagine it,
the key key of hello Chrissy and this whole body of agile methods is where you make the entire
organization. Self-organizing. And it doesn't have a traditional commanding troll approach. It
doesn't have anything like command and control.
There's no waterfall. There's no top down. It's very radical. It's okay. Icing in small distributed
self-organizing decentralized groups. It's called. Holocracy have a look. Um, there's lots has
been written around what, um, Zappos has done in the U S they're probably one of [00:05:00]
the pioneering Holacracy companies, but what's really fascinating about this.

This is really inspired and born out of agile methodology and agile thinking, agile values and
principles. So there you go. So this is one big bucket. Of the agile world, that sort of model
decentralized, um, way of organizing Holacracy. Yeah. Being the, sort of the showcase there.
So now I want to move on to sort of enterprise, um, Kind of a thing I want to move towards how
you might see agile in a more continuous, ongoing manner.
This would be, um, uh, an approach best used in enterprise. Um, you know, when you want to
create that enterprise rhythm and you want to do deploy it an approach that's around the idea of
improvement. So [00:06:00] you've probably, you may have heard of enterprise scrum. Uh, you
may have heard of Spotify is what we call squatter.
Effication. Uh, again, this has sort of an organizational flavor to it. The difference between this

and say the Holacracy approach is this still has the central governance still has the enterprise at
the center, so it's less decentralized. Um, and, um, you know, another great example of this
more enterprise flavor, um, is the Macado method, which is all about.
Continuous improvements on existing software systems. So incremental, make it 1% of each
sprint. And over time you have a better organization. And what's quite interesting is that there
are a lot of European origins have adopted this using Spotify. As this sort of poster child, if you
will, of this approach and this Macado method, or, um, X [00:07:00] scale is another kind of
flavor of this enterprise version.

Um, this has been, um, really quite successful. And so if you have a look at Spotify
quantification, and you're really interested in implying this continuous improvement approach,
then just Google around and you'll find some, some really interesting stuff around this. All right
now, the next one I want to go to is a, what we call more of a lean startup, um, more of an
extreme manufacturing, agile unified process flavor.
This is where at the hot we're starting to use some of the principles of. Just in time
manufacturing, uh, only writing code once it's been tested and validated, or as in lean startup is
experimenting continuously to validate your hypothesis before you build [00:08:00] stuff. Now,
why this is so interesting is obviously the risks with manufacturing.

If you start building the wrong thing and you've got your build of materials and you've got the
wrong components that haven't been tested, what this agile methodology, um, uh, grouping
does is try to de risk some of those bigger investments. And particularly if you look at the origin
of lean startup, lean startup was born because.
When Eric Reese wrote the book, he talked about spending a lot of money on his startup on a
bad idea. They built a bad idea in a great way. Because they didn't have that testing validation.
They didn't have that continuous experimentation to make sure that they are going in the right
way. So this is like the third big bucket okay.
Of agile methods. Um, so you can look into that. And I think the starting [00:09:00] point here, it
has to be go read the book by Eric Reese, lean startup. Okay. So now I've left the biggest and
the most popular, uh, version of agile methodologies. And that is scrum. Scrum is easily, uh, the
most popular, you know, Informal studies say that it can be anywhere up to 70% of the practice
of agile ends up being a, a version of scrum.
Uh, and there was some sort of related, um, kind of, um, Versions of the methodology. You've
got obviously Kanban, which I've mentioned. You've got crystal, um, and, um, some forms of
extreme programming. Um, they all largely coalesce around a more scrum, like, uh, approach.
And I think scrum for me has the focus.

Mostly on the team [00:10:00] and, uh, having a small autonomous team and it also has a
certain rhythm to it. And there's a really big focus on ...

Hello, and welcome to the bottom mat skills podcast. And Mike, since I'm the CEO of
quality science and we are once again, continuing our adventure. With agile software
development. And I hope you're enjoying this series so far, and I hope that you're discovering
some of the power of agile as an approach.

And today we're going to talk about values and principles that actually build up the idea of agile
software development and. The reason this is so important is the greatest thing about agile is it
has values and principles. And the most challenging thing is it has these values and principles,
and they often get confused as methodologies and.
[00:01:00] Yeah, it gets a little bit hazy and foggy in the world of agile. And, um, I want to kind of
cut through the conversation and give you some signal through the noise and help you better
understand how these values and principles really play out. And I want to kind of share with you
some of my, my favorite ones and how I've I found them to work in real life on real projects,
building software, ambitious first-generation products.

So I really want to. Sort of give you sort of my, my lessons learned from these values and
principles as well. And just remember if you're interested in the master class, where we go much
deeper into agile, just jump over to bottom up.io, where you can find master classes on agile
design thinking and a whole bunch more.
It's all totally free. So just jump over [00:02:00] there and start up an account. All right. Let's get
back into values and principles of it, agile and you know, the funny thing. About, uh,
understanding where agile really comes from is it's pushing off against the, the old school. Uh,
the traditional way of building software, which is generally been referred to was waterfall, and it
was slow, bureaucratic, and you'd often get bogged down in.

A lot of details that actually in the end, they didn't actually turn out to be the right approach. And
so the crazy thing is, um, where agile comes from is busting all of those problems that we have
with traditional software. So let's get into it and let's have look at the world of agile as it retains
to these full.
Specific values. So here they are value. Number one that builds up. This is like first [00:03:00]
principles okay. Of agile software development. Number one is that individuals and interactions
prioritized over processes and tools. Number two working software is what we want over lots
and lots of documentation.
Number three, we always focus on customer collaboration or, you know, the partner in our
project over contracts and paperwork. And number four is responding to change rather than just
following the plan. Now I want to break each of these, but they are really brilliant because they
solve so many problems.
From the top. If you want to focus on individuals and interactions, I cannot tell you, this is the
critical thing of agile. Uh, if you've got a small autonomous team building an ambitious new
product, it is all down to the key ways that [00:04:00] a product to own a business. Alice, a
designer. Um, you know, engineers, you name it, how these people work together, not just
update on their status, but how they look at the facts, how they look at the scope.
They look at the user stories and really work through each and every detail together. So you
really want to prioritize these individuals and how they interact with each other really, really
important. The second one, working software is more important than the comprehensive
documentation. The key thing here is your North star as if you've got great working software that
you're testing with users.

That is the problem. Anything that you focus on in agile, you can always come back to
documentation. But the source of truth is working software and particularly working software.
That's being [00:05:00] tested with users. This is essential. So you don't get caught up trying to
have lots of nice documents and binders full of documents, but the software actually isn't that
good.
You switch it around and you focus on working software. Now the third one is. Really about
collaborating, not only internally, but externally with all of your stakeholders. In fact, this is one
of the most time consuming yet. It is still the, one of the most important things that you need to
do is whoever the stakeholders, whether they're internal stakeholders and or external, bring
them into the picture, make sure.
Whether it's through scrums demos or showcasing the work as you do it together, make sure

that you employ the right collaboration experiences for all stakeholders. Often a lot of
stakeholders are [00:06:00] left out of the picture. They turn up at the end. They don't like what
they see because they haven't been able.
To contribute. And lastly, responding to change. It's such a, such a fundamental idea in agile.
Um, and the reason that it's such a strong value is one of the real pitfalls of waterfall is at the
beginning of a technology and software project. Someone would write. I requirements and
specifications document.
And then he is later when the software's finally delivered. It turns out that those requirements,
uh, those, uh, functionalities were incorrect or incomplete. And so agile is about continuously
refining them. Now that can feel a little bit chaotic, that can also be a little bit stressful. And there
are ways of dealing with that.
But fundamentally it's about being adaptive to what the best product is for customers. So those
four values are at the cornerstone cornerstone [00:07:00] of how to think about agile. And if
you're thinking now, Oh, geez, Mike, but actually what do we do? I'm going to give you some of
the principles, but I promise you throughout this series, we're going to get very specific into
individual roles and tasks, but it's essential to understand these values and principles.

Okay. Let's keep going. I'm just going to give you a couple of my favorite principles. If you go to
bottom up.io, you can get the whole list of all the principles in the agile master class. But I'm just
going to give you a couple that I really like. So one of the principles by which you can start to do
and to prioritize your actions in an agile project is always satisfying customers through early and
continuous delivery of value work.
I am a big fan, as you know, by now, if you've listened to the design thinking series on the
podcast, if you've listened to any of my work on bottom, up in any of the mass classes, work
with users, the [00:08:00] true Testa. Yeah. The true judge of a good product is your ability to
satisfy the end user. So focus on that and try and do it as fast, early and continuous as possible.
This is. This takes all the risk out. This takes out all the uncertainty, because if you have good
food back from users, you'll always know where to go. Now another thing about software
projects is they can get big and overwhelming. So this second principle I really like is always
break down, work into smaller tasks.
And the user story is at the very, very micro level of an agile project project. And I encourage
you really to have great epics themes and user stories when you're breaking down your work.
And if you want to know how to do that, we'll be tackling that later in this series as well. She
goes quickly to other principals that I, uh, I really do like, um, big one for me is [00:09:00]
recognizing that the best work emerges from self-organized teams.
Now this is a classic paradigm of freedom versus responsibility. So you do need people that
take a high degree of ownership in agile teams. But the message here is put people together,
empower them, let them self org...

040 agile intro raw
[00:00:00] Hello and welcome to the butter map skills podcast. I might pass since I'm the CEO
of quality science. And I'm a little excited today because we're starting a whole new series.
We're going to dive into the world of agile software development. So we've got like a 10 part
series coming up for you. Where we're going to explore the entire universe of agile and break it
down into some super handy, practical tips that you can use in your job.
And, uh, I hope you enjoyed the design thinking series that we've just completed. Um, along
with design thinking, agile software development is. So, so damn him. I, I really, I cannot
overstate the dramatic change it's made for me in helping [00:01:00] build brand new products.
And you know, the reason why agile matters, the reason why we should be thinking about it,
talking about it is agile is the perfect response to that.
Old approach to building software and products, which is called a waterfall. It was slow,
bureaucratic, and completely non adaptive. I, it was just do the plan, whatever we agreed. In
fact, agile would hold software projects. Ha but you would literally make sense the requirements
at the beginning of a project and you wouldn't.
Change those. And what was crazy about waterfall is you would only really embrace a user
testing just before you launched or just after you launched. And the great news about agile. It
turns a lot of things up on its head. Um, but [00:02:00] what it does is it brings testing with users
into the heart of every few weeks.
So this means that you can get more, uh, focus on, um, I product that actually works by being
customer focus, the products going to be higher quality. And by being in there more of a
continuous delivery, uh, mode, if you will, you're going to be able to get way more engagement
from the team. Engagement from users.
And I think it's far more than that. Just a way of building software. I think it's a way of organizing
companies, but I'm going to tell y'all a lot more about that over the course, the coming weeks.
So make sure that you, if you're going to enjoy this series, make sure that you stay tuned for the
entire 10 plus episodes of our agile software development series.
So I K I've [00:03:00] been talking up a pretty big game on agile, and you'll be wondering to
yourself, but what exactly is it? Well, let's set the context for agile software development and
moreover agile ways of working. And I want to you to think of agile as a set of principles. That
help teams build products at speed and it's super nimble and iterative.
Okay. So it's a set of principles. Now, this is really simple because what we'll discover later is
sometimes people get mixed up and think agile is a myth technology. It's actually a set of
principles. There are some great agile methodologies, and we definitely going to talk about
those as well, but at the heart.
I want you to imagine this is about small teams going super fast and probably speaking, you just
get out of their way. You give them empowerment, you give them a clear vision to hit [00:04:00]
and let them go for it. So let's talk a little bit about where. Agile hails from like all good things. It
didn't come out of a void.
Um, in fact, it builds a lot upon if you want to go really back into management theory, it goes
back to some of Peter Drucker's very famous thinking about the art of maximizing, the amount
of work that is actually not done. So this minimalist idea of only building things that work only
focus on core value for your user and for the business.
This goes. Back decades. Um, and at the real Genesis of management theory and management
strategy in the postwar era now moving on from that, I think one of the most, um, Important
examples of the early, early, early part of not only agile, but I would also say, uh, lean [00:05:00]
methodology is the Toyota production system house.
Now this Toyota production system was really at the heart of house. You know, Japanese auto
manufacturing leptons of the scene in the fifties, sixties, and seventies, and really challenged
the incumbent traditional manufacturers out of Detroit USA. And they had a couple of crazy
ideas. They focused on really shortening the time to market, really focusing on continuous
nature of manufacturing and, uh, it really standardized a whole, all new way of working.
You may have heard of just in time. Manufacturing that went on to inspire, uh, companies such
as Dell as well. And so it really was something that Toyota embraced in the early fifties. And not
only did that really establish the value of working in an agile way. And it also inspired a lot of
lean thinking, which we will [00:06:00] do a separate master class on cause that's jam packed

with goodies as well.
Um, so just kind of wrapping up some of the background. We've got Drucker and Toyota, some
real cornerstones of agile, but actually a whole bunch of guys got together. Uh, and this was
where we saw, um, the transition from being a manufacturing or management theory and
applying agile into software. So February, 2001, there is a ski resort in Utah called the snowbird
ski resort.
And basically, um, A bunch of dudes got together and came up with this idea of an agile
manifesto. And this is really inspired the principles and values of agile. And these are the kind of
three pillars of, of the history and the context of agile Drucker Toyota. And this manifesto, we
can plot everything that we do today back.
To, uh, these [00:07:00] three inspiring these three driving factors to create modern, agile
software development. And I just, for a moment, we'd love to get. Specific in talking about what
agile is and I'm going to is a form of agile, agile method called scrum to describe it. And we're
going to keep coming back to it time and time again.
And we're going to break down the different roles and practices and tools. So don't worry.
Everything's ahead of you here on the bottom up skills podcast now. We're thinking about agile
and I want to use this scrum analogy. And the best way I can describe it is every couple of
weeks, a small team do a sprint.
This is a sprint of work. They're largely autonomous. They work from a thing called a backlog.
It's a list of tasks and items to a list of, to do's if you will. And they're driven by. A scrum
[00:08:00] master who runs the rhythm and the team work with this idea of having daily scrums.
And at the end of the sprint, they have a retrospective and a review.
And the person that's really at the highest, the process of the product is the product owner.
There was lots of other roles as well, but. We'll get into those, but this is a, uh, a rhythm, a
cadence that you get into and you might on a project have six, 12, 24 sprints, depending on the
size of the product that you're going to build.
And, um, what you do is instead of with waterfall, having these enormous timelines, That lead to
products that are way late and way wrong. What you do is you try and make every sprint self
contained. So there's a body of work that gets reviewed and checked. So you can, it really
makes it easier to stay on track.
And unlike with waterfall, it's, it's much harder to get off track. If you use this. Agile software
development [00:09:00] approach. Now what's really interesting is agile is becoming something
much desired, not only in sort of high tech, uh, startups or, um, software companies, but it's
actually going way beyond the sector into business, more largely speaking, but here's the crazy
thing in a benchmark study that Deloitte and McKinsey did together in 2019, they found.
But when they talked to senior executives across a whole range of companies, they found that
...

Hello, and welcome to the bottom of skills podcast. I'm Mike Parsons. I'm the CEO of
QualityNet and we are at this second last installation of our design thinking series. And in this
episode, we're going to talk about how to test your product. With recruits. Now this is an
essential part of design thinking.

Everything you do. Should be tested, should be validated with users. And what we're going to
talk about is how do you get people together to test your product? And I'm going to focus more
on the latter stage. So I'm going to assume your product is starting to come to life, at least in
wireframes, maybe in envision or Adobe XD, and you really want to get some feedback now.
Have you listening [00:01:00] to this and you're thinking, Oh, I need something a little bit more
earlier stage. I want you to go back a few episodes in the podcast. Cause we go quite deep into
how to do quantum qual research at the very beginning of the journey of building a new product.
And of course, if you'd like to know.

Much much more and go a lot deeper. You can get our free [email protected], which
goes extensively into how to use survey monkey. There's a masterclass on that. We have
obviously the design thinking masterclass and we have a rapid prototyping, a massive, so plenty
of there are much, much more, all free.
Go check it out. All right. Let's get back to user testing. The first thing I wanted say is you should
be testing all the time. Yeah. Yeah. If you're using an agile team structure and doing sprints,
then every year, two weeks, the work should be tested before it goes to the client. Um, it should
be tested before it goes to the stakeholders.
It's really, really important to always be checking in because you don't want to build a house of
cards. You don't want to [00:02:00] assume things work when they don't and build sprint after
sprint. And at some point, you're going to realize you're wrong and you're going to have to pull
back all that work. So it should be before you launch during launch and after launch, in fact, a
testing paradigm or use a centric paradigm, or even brought us to a design thinking paradigm,
you should be testing.

All the time, all the time. Okay. So we've got some good material to test. We've got some sort of
clickable prototype. We're want to get some feedback. I think the most important starting point
that I can share with you is you've got to go out and get a. Testers who are in your target
demographic target user case, uh, the persona, the archetype, however, you're defining your
customer.

Please make sure that they meet that criteria and make sure [00:03:00] that you can test them
in a fair and legitimate way. Sir, make sure that there's plenty of time explain you're doing a test
and don't rush through it. Make sure. That you have time and space to test properly with the
right people. Now you might think to yourself, this sounds incredibly straightforward and
sensible, but you're right.

But here's the thing in the rush of trying to launch a product, build a company, build a product.
We often skip over these things and we don't do those basics. Right. And if you don't have the
right person in the test, well, All the testing sites are invalid, or if you have the right person, but
you haven't created enough time, you haven't made sure everything is right.
You've also at the time. So less, let's kind of, it's getting to now, you've got the right person, you
know, you're testing or someone is right. Riding the target zone for your new products. I want to
take you through how you might. A test with them. Now, the core of product testing, [00:04:00]
my strong recommendation would be to do task based testing, meaning set the user a task and
watch them as they attempt to complete the task.
Please avoid it. All costs falling into some sort of diagnostic chitchat. You should have done that
ages ago. This is raw. Black and white binary. Did they complete the task? Were they able to do
it fast? Easy. And did they do it to their satisfaction? So task based, make sure you say, I want
you to find a restaurant.

I want you to book an appointment with a hairdresser or Ababa, give them a specific task like
that and then watch how they might go about it. Now after you give them any sort of task based
testing, you can ask them all sorts of questions. And we'll talk about some of the best ways to
do that, but I want to give you [00:05:00] three types of task based testing that you could use.
The first one could be usability testing. And that inherent thing that you want to do with usability
testing is can you remove as much friction from the journey, from the flow, from the experience

as possible? So that's usability testing. Now you might, uh, have user groups with special
needs. Let's say they might have some sort of visual impairments.
Maybe they might be, um, Using your product in a high noise, high distraction environment,
there's all sorts of things that could affect how you qualify your usability testing. And you want to
try and create as close to real life conditions as possible. So that's usability testing. The other
thing you can do is you can launch your whole product to a closed user group.

Maybe a traditionally may have called that like a beta group or Biddy test is. Um, you might
even build a whole MVP and give it to a small cohort of people. That's another way you can
[00:06:00] look at task based completion now. What you might have to do as you move into this
more broader type of testing, you might need to use tools such as Mixpanel, um, optimizing your
Google analytics to look at it.
So I would always want you to have some usability, usability testing in person, really to get that
viscerally side of how people are completing tasks now. As we were talking about this, you
might do a combo of in-person usability, testings, uh, you know, have a beta version. And as the
product goes live, you can continue to test.
And what you could do is using tools like Optimizely, you could run different tests where you
serve content or interactive elements in different order, in different ways, for different types of
users, based on IP address and location. Might do all sorts of different variations. I think what
you want to be able to do is look at their PA capacity to [00:07:00] complete an event, to
complete a task.

This has always been the gold standard for me when I'm working on a product, if it's useful at
all, there's a task involved and you're helping people get that done. Now, if you're doing this in
person, You want to take, uh, transcripts, uh, you want to ask questions at the end of the
experience, um, and you want to.

Uh, record that, um, with your memo app on your phone, you want to, uh, transcribe it, make
notes, um, for sure. Um, that's really, really important. If after the experience you ask them a
series of questions. Now, the other thing you can do is you can run a net promoter score survey,
very simple. How likely would you be to recommend this product to friends and family?
You can, um, do that after the test and if it's a no and category a or even after you explain the
idea, you could ask an NPS, [00:08:00] then you let them do the testing. After the test, you
actually redo the MPS and see if you can create a shift in the advocacy because after the
experience you might see your capacity.

To increase advocacy, sharing and word of mouth. So NPS is a, is a very, uh, Powerful thing to
do after if you want to get into like a really heavy corn statistic, SQL approach, what we would
do use on any of the three tests that I mentioned would actually look at task completion rights.
This would mean that if your.
At the...

hello and welcome to the bottom of skills podcast. I'm your host. My name is Mike
Parsons and I am the CEO of quality teams. And we have come to a special moment. Ladies
and gentlemen, we have arrived at the last part. I think it was like 14, 15 part series on design.
Thinking, Oh my gosh, it's been a journey.

And if you can believe this, the next series that I'm going to do for you is going to be on agile
ways of working. So no rest for the wicked here, but we're going to wrap this up with a episode
dedicated to how to share your product insights. Now, this goes to really one of the hot of the
biggest challenges we have when we're in [00:01:00] teams and were designing, creating,
building, whether it be product or a service or an entire business.

Um, the truth really is, you know, We never really built a product on our own. There's always a
couple of people involved for at least half a dozen or a dozen. And as soon as there's two
people involved, there becomes a question of alignment. Do people really get, uh, what we're
trying to build? And as you've heard me talk about so much design thinking is not about
guessing what's going to be nice.

It's not trying to be the ultimate. You know, tastemaker with this fantastic aesthetic and just
picking something that is on a whim or just a result of your sheer brilliance. No, we love to work
hard and serve users test and learn with users. But once you've done all that hard work, there's
one final step.
And I'll tell you why. I think this matters so much. I have seen [00:02:00] so many. Wonderful.
Creative designers, UX specialists, UI specialists. You name it. Struggling to share what's inside
of their head, what they may have learned with users, um, to the broader team and how the
classic one might be between a UX or UI, a BA or a developer who are all coming at the
challenge of the product.
In a slightly different way. So if you're doing any sort of design thinking, work, sharing your
testing insights is a key opportunity to get everybody on the same page. And what I hope to do
now is to help you tell your product story, and this product story is going to be rooted in user
insights, user testing, learning, and validation.

And one of the key things we can talk about is. [00:03:00] How are we going to capture what we
learnt? How are we going to like put it in a vehicle and asset, how are we going to present it?
Now, one of the things you can definitely do is share your, um, output, uh, the sort of.
Conclusions that you can draw upon your research in updating your user personas, that you
should have started at the beginning of any project and they should continue to grow and evolve
throughout the entire process.

You should have something like a user journey map. Again, we've covered what that is in this,
uh, design thinking series. So just go to one of the older podcasts, you'll see it in the list, or you
might even have. Something like wire frames, which might help you kind of bring the product to
life. If you've tested well, you can update those.

If you want to get a little bit more strategic, you could use a user matrix, an affinity diagram, or
an empathy map. These are all classic [00:04:00] tools of design thinking, gurus who are trying
to kind of capture the learnings and the insights. In a particular way. And you know, there's a,
quite a science and an art to picking the right one, but you should check out our master
[email protected], where we get a bit more into those.
And we talk about how to do them. If I was to pick one thing, um, that would be really essential.
And I do this on every single product that I work on is. I would use a value proposition, canvas,
where you essentially outline what the pains are experienced by your users and what gains
they're looking for and they're trying to get done.

So that's all on the right hand side. And on the left hand side, you match map, correlate these
with pain relievers. And gain creators that define, determine and inspire the feature, set the
product set [00:05:00] that you're working on. This value proposition. Canvas is so good
because it's incredibly simple, but what it does is it forces you to map, do your gains.
That your user experience, your user experiences, are you actually building gain creators? And
if the user experiences pain, are you relieving that pain? I love the simplicity of this. The value
proposition canvas for me becomes a simple essential tour at any executive or designer or
anyone in between can refer to an ask.
Are we getting it right? Do our features. Mapped to the jobs to be done. Do the gains really get

created and are we relieving the pains? The value proposition canvas for me is a great exercise
because it makes your, makes you really work on the stuff that you learned in your user testing.
Um, and it really makes you ask yourself, Hmm, have I really validated the gains and the
[00:06:00] pains?

And it provides you with a really good baseline now. One of the things that you might like to do
either before or after your value prop canvas is you might've conducted a big research and
everybody might be really eager to learn, like, okay, what did we learn from this? Now, for
example, I'm working on a product and we've already done.
Two rounds of quantum surveys, two rounds of qualitative interviews. And we're about to do one
of the first user tests where we're going to test the, uh, the first designs of the brand new
products. Now what's essential is to make sure that whatever we can to get of this upcoming,
uh, test is, um, we need to find a way to tell the story.

And so I've got a three part. Approach. It's a bit of a model that you can break down your
presentation into and. [00:07:00] What I love about this is it has a very clear separation from
data from insights and recommendation. And, um, the reason that I use this is it really helps, uh,
create clear outcomes and it helps everybody stay on track on why those outcomes are so
important, why those next steps are important.

So let's dig into this three-part model of presenting. Your design and product ideas. First of all,
data for me, a piece of data, great example is 22% of our customers are aged 18 to 24. So
when you present data, you try to be as black and white, as clear and as binary as possible and
specific. Um, and. You don't have to draw any insights or recommendations from this.
I quite like the idea of just passing out the raw data. [00:08:00] If it was a survey, each question
has a clear outcome, a clear table or a chart that tells us the data. So just present. Data first,
then you have the interesting job to do is you can say, well, what is an insight? Um, and you
might say, well, it's fascinating that, uh, East coast customers have a much stronger preference
for mobile in this age group than those on the West coast.
That's actually. A really, really powerful insight because you might need to go and validate, uh,
why there's such a discrepancy because it's unusual, but that's what we'll get to in a second
with the recommendations. So you've got the data and then you can draw a really interesting
insight. Now, one of the key things that you're going to do is come up with lots of data points in
insight, whatever you do.

If you're presenting the results of a big test or a big piece of product [00:09:00] work, I would
challenge you just come with 10 data points. 10 insights and 10 recommendations. So
essentially 10 ideas that run through those three vectors. The reason why is I rarely see even
the smartest people I've ever worked with really able to hold their attention beyond that.
And that's a very good model. If you can get it under 10, even bett...