[Music]
Do that.
Okay.
Um, I guess, uh, welcome to this. Is this the fifth? Fourth? Fifth?
Fifth.
Um, live workshop that I’ve been doing. This one is introduction to the sprint review. So we’re going to dive a little bit into how the sprint review works and maybe why it’s not working for us because in some cases, I’m sure it’s not working.
Um, and how to do it a little bit better. Hopefully, this will be a good interactive experience and I’m going to try my best to do better with the timing because last week’s, uh, not last week’s, two weeks ago, the um, Kanban session, um, that was the main feedback was Martin’s timings up.
So, um, I’m going to try and do better at that. Peter is a veteran of some of my sessions, so he knows that my timing quite often sucks. So, um, that’s just the way it is sometimes when the participants have lots of awesome information to impart. Sometimes it’s more interesting to listen to what people have to say.
Uh, so we have eight people in person just now. Um, I’m sure a few people will turn up as we go. Um, but I have, as usual, a little icebreaker for us with some questions about the, um, let me just unlock them for you. Unlock.
Um, with some questions about the sprint review and I’d like you to drag, have a read of the different questions, um, and drag either a tick or a cross onto, um, onto the hexagon on whether you agree with that statement or not.
I did these ones a while ago, so I don’t actually remember how many trues and how many falsies I’ve got, so we’ll need to take a look.
Oh, has anybody got things dropping behind? Nope? Awesome. Just making sure because that’s sometimes a mural problem, a tool problem.
Uh, one perfect assistant for you. [Music]
I’ll put another four minutes on the timer for us to go through this and then at the end of, um, this exercise, I’m going to lock the meeting.
[Music]
We had lots of disruption in the first session with people kind of hopping in and out of the meeting during the session. So, um, we lock it. It does mean if you do drop out accidentally, um, because of internet or whatever, you’ll not be able to get back in and I apologise for that.
Um, if you were, uh, if you’re still waiting to participate, you can click the links and get into the meeting before it closes.
It interferes with my ability to quit breakout rooms when people are joining and leaving and joining and leaving and then ends up in a breakout room on his own when it’s supposed to be a pair and he’s like, “What the heck’s going on?”
Yeah, I normally end up alone somewhere.
It’s a time when I actually can do some work.
Okay, well, let’s not use that button. How do you do?
I’ve got a new keyboard function lock. That’s what I want. F11. There we go.
Um, okay.
We have, well, there’s some that are not ambiguous at all. Number five. This is the only event where stakeholders are regularly invited to participate.
Everybody’s on the same page for that one for sure.
Let me grab a big tick. I agree with everybody on that one.
During the sprint review, the product owner may share budgetary and likely release dates.
I’m going to put another big tick. Oh, I’ll grab the big tick because then it’s already the right size. There we go. I’m going to put another big tick on that one.
We want to, we’d like to use the sprint review as one of the primary communication mechanisms where we’ve got everybody together.
Right, so it’s open, it’s transparent. The stakeholders are there, the team is there, and perhaps leadership is there and the product owner is there and we can communicate things in an open and transparent manner.
And it allows us to maybe have or not have or deal with some of those things that come up when somebody else thinks their stuff is more important than everybody else’s stuff.
Maybe they can openly and transparently say so and why and then find out they’re wrong because everybody else has other ideas, right?
That’s kind of the value in that, in this event.
Stakeholders and the scrum team collaborate on next things that could be done to optimize value.
That’s another green tick there.
And we want to, what’s next, right? Something might have changed, so we need to figure that out.
Uh, then we get number three. I’m not doing them in any particular order, I guess new microlighter might have made more sense, but that’s not the way I started.
Number three. During the sprint review, the product owner may present a forecast of progress towards the product goals.
Right?
Product goals are pretty important in scrum. They help us focus the product backlog and gives us, ah, what’s the best way to describe a product goal?
So, we’re going to have some kind of vision or strategic goal for our product and then that might be too nebulous, too far out for the people doing the work to actually connect to that idea.
So a product goal is an intermediary strategic goal that is far enough out that it’s a bunch of sprints but close enough that we as people doing the work can actually see how the work we’re doing contributes towards that thing.
Because sometimes the vision is, you know, some solve some esoteric customer problem and it’s difficult to see how we get there because that’s two years away.
Um, so how do we get something a little bit closer to connect to?
Uh, number one. The purpose of the sprint review is to assess if the product increment should be released to market.
I would say yes, it is. If your stakeholders are sitting there saying we can get value from what is what you have done so far, why would you leave it sitting on a shelf?
Why wouldn’t you ship it to customers?
Now, you might not ship it to customers if the cost to ship to customers is too high, right?
But then I would want to have a conversation about why is the cost to ship to customers so high?
How can we fix that problem?
Shouldn’t each increment go to the, you?
It should be released, but regardless, it shouldn’t be part of the review to assess if it can be shipped.
Ah, so I think it’s saying if it should be shipped.
So if we have a potentially releasable increment at the end of the sprint, we get together at the sprint review and one of the outcomes might be push the red button to actually release it.
It actually goes to production.
Um, scrum, the scrum guide doesn’t require or enforce in any way that you do ship to production at the end of every sprint.
It just requires that you have a potentially shippable increment, a usable increment.
Um, I would add to the scrum guide and say yes, you should be shipping to production at the end of every sprint.
And if you can’t ship to production, I’d want to figure out why and how do we fix those things?
That statement just had two negatives and didn’t catch both of them, the assess and should, because I thought assess if, yeah, I missed the should instead of, yep, that’s probably my bad English of I know of Norwegian, so he obviously has better English than the rest of us for sure.
No, I’m just the two negatives caught me.
Okay, yeah, that’s my experience of being in Norway as I say stuff and people are like, “Yeah, that’s wrong.”
We don’t speak English in Scotland, do we, Peter?
No, no, no, I just, uh, yeah, I’m just saying the two negatives in that statement caught me off guard.
Yeah, what did I just, I missed this should, the assess and should release to production.
Okay.
Uh, what we got left? Number two.
By the way, that’s the reason why I’m the red dot.
Okay, that’s okay. You did not, you were not required to own up to that.
Um, station two. This is a four-hour time box event for a one-month sprint.
That is what the scrum guide says.
You have up to four hours for a sprint review, right?
And it’s usually, it’s proportionally less for shorter sprints.
So if you’re doing a two-week sprint, you kind of have up to two hours, I would suggest.
That if you’re not having enough conversations to fill that time, that for me would indicate a smell.
I’m not going to say it’s wrong, right?
If you do a 15-minute sprint review and everything is awesome, you’re building the right thing, your stakeholders are happy, they understand what’s going on, your team knows where you’re going, um, and you can do that in 15 minutes.
Oh, awesome, right?
But in general, I would see it as a smell if you’re not able to fill that time or at least fill a good proportion of that time.
It would mean to me that we’re maybe not getting to the crux of the conversation, we’re not communicating enough, maybe we’re not getting enough feedback from our stakeholders, we’re not engaging with our stakeholders.
Um, for them to provide feedback because I don’t know if you’ve noticed, right?
But if you have a meeting, whether it’s Teams or Zoom or any platform, and you ask a question and there’s 20 people there, you’ll generally have tumbleweeds.
You won’t have anybody saying anything.
If you do have people saying something, it will be the loud people who always talk or the hippo, right?
You heard that expression, that the highest hippo, highest paid individual in the room, that’s the hippo, right?
So either people don’t feel like they can talk, they don’t feel like it’s a forum within which they can voice their opinions, or they don’t really feel invited, they feel like it’s a platitude, right?
So there’s a couple of techniques you can use in there. One is, um, I can’t remember the name of the technique, but it’s you make sure you get an affirmative or a negative from everybody in the room.
Everybody has to say either yes or no, and we take them not saying anything as they totally disagree with what we say.
So are you happy with this product? I want to hear a yes from everybody.
That can be a technique you can use to get to that person that’s going to say, “Well, no, this is a problem,” right?
But maybe they didn’t want to say anything.
And to encourage them to talk, the other way is do breakout rooms, do smaller exercises, leverage those liberating structures.
I’ll talk about some of the options that I have seen work.
Um, I would also say that everything I say is what I’ve seen work in the contexts within which I’ve been working.
Um, so Peter may have things that work for him but don’t work for me, or may have things that work for him and don’t work for me, and it’s culture-specific as well.
The Brits can be fairly loud and obnoxious in meetings; the Norwegians could be fairly reserved and not boisterous at all, right?
So you need to take that into account, who is attending your meeting and what is their culture, even within different companies.
Uh, and then the last one, number four. I don’t know why I ordered them in that weird way, but there we go.
Uh, sprint review has the highest number of participants, making it an expensive event.
Okay, so this time, all of these statements are in fact true, and the sprint review is usually your most expensive event.
Right? You’ve got two hours, you’ve got the scrum team, so the product owner, the developers, and the scrum master, and a whole bunch of stakeholders, business people, people who care about your product.
The most people at any time are in that event, therefore it is, by definition, the most expensive event you have.
So you want it to be valuable, right? If you’re wasting people’s time, you’ll find that participation will decrease over time because people will stop coming back.
If you don’t show people anything they care about, they’re not going to come back next time, right?
Even if you don’t show them anything they care about, if they’re not engaged and don’t see anything they care about, they’re definitely not coming back.
So we need to figure out how do we encourage people to participate in that event.
Does that sound reasonable for my answers? Reasonable? Anyone to disagree with anything?
Oh, I got a little heart pop up there. That’s pretty good.
Using the tool.
Using the tools.
Um, okay, so let’s look at what a sprint review might look like.
Okay, so I’ve got a couple of pieces that I want to talk about here, and then I’ve got some little exercises around it.
So the first piece to think about is what’s the purpose of the sprint review in scrum?
Peter, I know I’m putting you on the spot, but what do you think the purpose of the review is?
Feedback.
Right, it’s part of our empirical process control system, which scrum is trying to implement.
And empiricism just means feedback. It means look at what happened and figure out what to do differently next to make what happened better the next time around.
Like that, those empirical feedback loops, inspect and adapt, all different ways of saying the same thing.
So the sprint review’s outcome should be an understanding of what we are doing next.
And in scrum, we store that information in an artifact to provide transparency called the product backlog.
Right? That’s where we’re transparently reflecting what are we going to go do next, what’s the next most important thing to do, what’s coming up after that, right?
That’s where we’re reflecting that.
So we need to walk out of the sprint review with an updated product backlog.
Uh, yeah, I can put, uh, could you put the link for the mural in the chat? Just copy it from where you’re talking.
And you have one more question in the chat as well.
I haven’t had that. It says, can you like, what happens? So Carlos is asking what happens when the product owner is absent in the sprint review? Could you share your opinion on that, please?
That is a very good question. I am going to share it with a little story. I worked with an organization in Horton, which is about, I don’t know, it’s about two hours south of Oslo, I think it is. Two hours southern, one hour, two hours would train, one hour, yeah.
I always went on the train, so it was two hours.
Um, and I had, I worked with this team and they were very, I’m actually going to say depressed, right? They were not a happy team.
Um, they had a very negative outlook on the work they were doing and what they were doing, and I was trying to figure out what the problem was.
Right? So I go to the sprint, the events and see what’s going on, and at the sprint review, I just asked them, I didn’t see anybody new, so I was like, “Who’s the product owner?”
“Oh, oh, that’s Thor, right? He’s not here.”
Like, is this, is he usually here?
“I don’t know, he doesn’t normally come to the sprint reviews.”
How would you feel as a team if your product owner thought so little of the work that you were doing that they couldn’t even be bothered to come and see what it was you did and how well it was done?
How would that make you feel?
Probably make you feel like nobody values your work.
[Music]
Right?
What are the three things that we need to feel like we can work well as from at Drive Dan Pink’s book Drive?
Let me remember what the three things were.
It was autonomy, mastery, and purpose.
With the three intrinsic motivations, once you get money off the table, when we’re not worried about putting a roof over our head, autonomy, mastery, and purpose.
We want to feel like we’re in control of the work we do, right?
So scrum facilitates that with our self-organising teams selecting the work at sprint planning.
We want to feel like we’re good at our job, right? That we’re learning more things, mastery of our profession, right?
And that manifests both in professional scrum, right? We’re doing that part well, but also engineering excellence.
If you’re a software team, you know, are we doing DevOps practices? Are we getting value from our product? Are we continually shipping it to production? Are we always increasing quality? Are we learning from each other?
That’s that mastery.
And then purpose. Are we building stuff that matters?
Do we feel like the stuff we build matters to other people? Because otherwise, why do I get out of bed in the morning if what I do doesn’t matter?
Okay, well, I won’t do it then, and we’ll have the same outcome.
So how do you create that purpose for people?
And the product owner turning up to the sprint review is probably one of the first steps.
If you can’t get the product owner in, you probably can’t get the stakeholders in either.
And isn’t he supposed to get them in at least on the, that’s one of his jobs as well, to get them together to showcase what’s happening?
And part of the problem I found for this team was that the product owner also wasn’t doing the product backlog.
Therefore, the team was building stuff that the product owner didn’t care about because the product owner didn’t care what they were working on enough to go update the product backlog and tell them what to work on.
Right?
So it was one of those vicious cycles of spiralling down to mediocrity.
And the question is, what was he actually doing to have the title product owner?
Sounds like he was not doing anything.
So, but this is where we get to that difference between do I have the job title of product owner or am I fulfilling the accountabilities of being a product owner?
And I don’t really care about the job title part. You can be called a delivery manager, you can be called a product manager, you can be called a project manager, right?
I don’t care what your job title is.
But somebody needs to take the accountabilities of the product owner, um, which is making sure that there’s a clear, transparent product backlog that reflects transparency of the future that, um, everybody on the team and the stakeholders understand what those things are and then actively managing that going forward into the future.
So if those things aren’t happening, that’s where I would look. Who’s supposed to be doing that?
So another question in the chat there. How do you get outcomes from the user?
Could you recommend some tips?
Now, I’m not sure I understand outcomes from the user, so maybe you need to explain a little bit better, but I think I might answer that question as we go through.
Okay, how do we get feedback from the user maybe?
Um, or maybe it could also be that you’re asking how do we know what the outcome’s supposed to be rather than just being given solutions, which quite often users try and give us solutions.
So I’m not sure what you mean there, Carlos.
Andre is asking an interesting question as well.
But can the scrum master be asked to back up the product owner in their absence?
Right?
And I would ask the question, if a product owner is doing their job right, they are taking those accountabilities, then they should be knowing what’s happening in the marketplace, what’s happening inside of the business.
Uh, they have relationships and manage relationships with stakeholders, whether difficult stakeholders, negative stakeholders, they still need to manage those relationships.
And they take all of that information of what the team wants to do, what the technical realities of the product is, what the business needs are, what the commercial realities are, and they funnel all of that information into here’s what we’re going to do next.
I’m not sure that I have often seen scrum masters that have the knowledge and skills to do that, right?
So it’s like in a different set of experiences.
I’m not saying it can’t happen, right?
But I would probably prefer a business analyst to be back up for the PO because they’re going to have a better understanding of what the business needs than the scrum master might have.
Or maybe the scrum master is your business analyst, in which case maybe yes, right?
There’s no real rule around that.
Ah, so Carlos is asking how do we measure the outcomes?
Um, let me kind of, let me put a pin in that and you ask that in a little bit, okay?
Um, because I think we might get to that.
Um, so what do you think we need going into a sprint review?
What’s, what’s, I mentioned a couple of things as part of this funnel, right?
One of the things that the product owner needs to bring into that story in order to be able to review, discover, and rearrange the product backlog to reflect transparency in the future.
What should we show? What should we have on here?
You have the sprint goal from the last sprint, so that’s what you should be measuring yourself against.
Because maybe we’re measuring our, yep, we are likely measuring ourselves against did we achieve the thing that we committed to?
Yeah.
What else is important in this product strategy?
Giving us the direction where we want to go so we can align flex strategy.
Yeah, absolutely. What’s our overall strategy?
I would suggest that might be a combination of the product vision and maybe the current product goal, right?
But maybe there’s more information there, so I’m happy to put all of those things on the list.
There’s probably useful information.
What else?
Remember, your product owner is spending the money.
They’re deciding what we’re going to go work on.
So what do we need to discuss in order to try and be as right as possible at this point in time in what we’re building next?
So the value of the product backlog items.
Yeah.
The value contained within the product backlog.
What about we just did this two weeks ago?
Let’s say we’re doing two-week sprints.
We just, we’re doing two-week sprints two weeks ago.
Um, what’s changed in the last two weeks?
You’ve discovered more.
Ace or later wants you to inspect the outcome in the chat.
Yeah, so the, the, I’m, what is the outcome? What’s the result of all of our work?
The increment.
Yeah, we need to inspect the increment.
The product has changed in the last two weeks.
Maybe that means some of the stuff that’s on our backlog we don’t need.
Maybe that means that there’s other stuff we do need because of whatever we built.
Right?
But there’s also changes in the business, right?
What’s happened in the business in the last two weeks?
Is their needs and desires exactly the same as they were two weeks ago?
Isn’t that part of just having the backlog always ordered according to what’s required or what’s the changing tide in the business?
So this is the moment where we have all of those stakeholders as well as the team together.
So you mean more reordering the backlog based on what has changed, not because if there’s a change for it, because otherwise I would expect that to be always present in order backlog.
So maybe there’s a change that the product owner knows about, but maybe there’s a change that they don’t.
Yeah.
What’s happened in the business?
And then perhaps market changes.
If you’re building a commercial product, what’s, what have competitors been doing?
Right?
Maybe that’s going to impact how our priorities have changed, right?
What do you think happened in the sprint first sprint review at the Microsoft Teams when lockdown happened?
Right?
We need the world’s changed.
We need to throw out this backlog and what do we need now?
What’s the most important thing we can do to help solve our users’ problems now, which might be completely different from two weeks ago, right?
I would argue that is a massive change that you don’t want to wait for the sprint reviews.
I would definitely agree.
Probably it requires a special session and something bigger happen.
Yeah.
I used a massive example, which definitely I would agree or would probably have some special things happening.
Um, but what’s happening in the market?
What competitors are releasing?
Maybe they’ve released a feature that means that users are starting to gravitate towards your competitors rather than your product.
How do you get ahead of that?
Headed off and do that.
So we’re going to take all of that information, present it in some way, and bring it into everybody’s consciousness, their frontal lobe, so we can noodle on it and have discussions about it.
So we don’t just need stakeholders, but we need the right stakeholders for the conversations that we need to have.
So you’re right, the product owner probably needs to have some understanding of what do I want to discuss walking into the sprint review so I can invite some of the right stakeholders.
Right?
Some stakeholders are going to come every sprint because you’re building stuff they care about, so they want to provide you with feedback.
So stakeholders is kind of a catch-all word that they use in scrum, which just means anybody who cares about the outcomes that the team’s working on.
Right?
So they could be users, could be business people, could be purchasers, could be anybody.
I worked with a company in the UK, and they ended up having to, they had one of those, um, like all hands meeting rooms in their company headquarters, and they would fill that for a sprint review.
They’d be hard pushed to fit the hundred people that turned up to see their sprint reviews.
Right?
But it took them months of what do you really want?
And once you start building things that people want, they’ll want to come and provide you with feedback.
Right?
They don’t want to provide you feedback on stuff they don’t care about.
So maybe share the goal, and then does everybody remember what the sprint goal was last sprint?
Perhaps not, so we need to share that as well, and again that would be the product owner sharing that.
And then maybe in some way we want to demonstrate the working software.
Who’s best placed to demonstrate the working software?
With the team, wouldn’t it?
They’re the ones who just built it.
They should be able to explain to the stakeholders what it is they’ve done and why it matters to the stakeholders.
We’re building value after all, not features.
Right?
Nobody really cares about user stories and features; they care about value.
What do I get from what you’ve just added? Tell some stories.
Right?
That’s the way I, I, I, storytelling is the best way to do that.
Um, so there’s a number of techniques that I’ve seen work really well in demonstrating the software, um, depending on how many, if you’ve just got one team, right, doing a presentation, maybe they just present, “Here’s what we changed,” right?
If you’ve got ten teams, that might take too much time.
So, uh, maybe you need something that looks more like, uh, have you seen in those American movies when the kids have their science fair at the school?
And you’ve got a bunch of stations, each presenting a different thing, and people go to the things they care about?
That’s the science fair model, and that can be implemented virtually as well with breakout rooms, and there’s various techniques for that.
Um, but doing that might be good.
Uh, doing some kind of shift and share if you’ve got a lot of stakeholders.
Shift and share is when you send people out to breakout rooms, and each breakout room is a particular feature or part of the product that one of the teams has been working on, and then you have the attendees move to the next room, the next room, the next room.
Uh, in order to facilitate that, I’ve done that one in Teams, um, and it works in Zoom as well.
But how many teams should a sprint review have? Shouldn’t it be per team kind or rent review per product?
So if you have ten teams working on one product, you show one unified working increment to the stakeholders because you’ve only got one product.
So we’re doing a review of the increment, and we have one increment.
We don’t, ten teams working on the same product don’t create ten different increments because then that’s not integrated together.
Therefore, it wouldn’t meet a definition of done.
And that sounds good.
So what a lot of teams do, or what a lot of product management does, is they create some kind of alignment in their product to minimize the number of people that are part of each of these stories.
Right?
So if you look at the way, and the example I always use examples from the Azure DevOps team because I’ve been working with them for a long time, but they all over the part of the eight years of their transition towards agility was they shifted their product from one big ball of string, right, to almost like verticals of here’s a, and it’s now called Azure Boards, right?
The graphical representation of the work that you’re doing.
So there’s one product owner for one product, and then that product owner maybe has two or three teams working for them, and those two or three teams are contributing to that single unified product.
So you have one backlog, one product owner, one maybe one sprint planning or like a pre-planning and one sprint review.
Yeah, but would you do one sprint review for all five products in that?
If I had five products, different products, I would maybe have five different reviews.
Yes.
Yeah, but your Azure DevOps is now becoming a mixed sample or mixed example because now they’re five different products, which each of them, so at the small scale, right, there is only one right answer: one product, one product backlog, one product owner.
Right?
But once you scale up to larger interconnected systems, maybe some of those systems are their own products that can be shaped on their own.
But I would suggest if it ships together, it needs to be reviewed together.
Right?
So if you have a product where you’re breaking it up by component rather than by vertical value streams, then you probably need, you probably forced into the larger review where you’ve got one bigger product.
And now when you do have a much larger review, something the Azure DevOps team did do was prior to their sprint review, every team would create a video to present the demo of what it was they created and send that out to everybody.
So it’s been my experience for the big projects or big programmes to do one demo for the whole project product, however you want to describe it.
Um, and at one level, you could say, “Well, I was looking after data migration. Did I really care that much about the user experience at the other end of the data flow?”
But it was still useful to hear someone say, “What we want to see next sprint is we want to see the events.”
So then that would actually inform me why people were then chasing me to migrate events from the database through the entire value chain.
So even though I normally didn’t care, it actually provided me and my team with some useful feedback.
Um, they, we can’t load this data, whatever x, y, and z data, so we’re not going to display in the UX for another couple of weeks.
So that would inform the guys at the other end of the flow, “Well, let’s not plan any work around trying to get that data in because the migration team aren’t going to get it to us for a few sprints.”
So it is useful for everyone to hear at least five or ten minutes what everyone else is trying to achieve.
Yeah, the other teams are also stakeholders to your input or output.
Maybe some of those teams are providing output that is your input, right?
And maybe you’re providing output that is their input. They’re blocked from delivering some features until you’ve got something there for them.
Right?
So it’s that whole context that is important in the demonstration.
And so I do agree that there are scale issues, and you have to figure out what practices work.
Uh, the Nexus framework, which is scrum.org’s scaling framework, encourages having a single sprint review, but it does talk about it being for up to nine to ten teams working together.
If you get more than that, you probably want to spread it into, I think they have a, I can’t remember what the phrase is, but it’s Nexus of Nexus.
Right? You might have multiple nexi, uh, that roll up to a single product.
It’s just more complicated, and the example that I think sits well with what you’re talking about over is I think about the Office team, right?
The Office team, SharePoint is not really that dependent upon Word, but Word exists also as a separate app but also inside of SharePoint.
So maybe there is a lot of crossover, um, but they’ve got nine hundred people-ish working on that product.
Um, so how might they organise that to be, to get the information to the people that need it, the feedback from the people that need to provide that feedback?
Um, it’s figuring out what works at scale.
There are no hard rules at scale; there’s so many different options there.
Yeah, I’m just seeing some, you said it was up to four hours.
Yeah, I know it’s just a number, but up to four hours for a one-month sprint, and you should be able to fill it.
But then if you are done, three teams, are you at twelve hours then?
No, it’s still one sprint.
So what I’ve seen work, and actually what one of the teams that Peter was working with, um, they had a tight time box inside the sprint.
Maybe each day, I think there were six teams, and maybe each team gets seven minutes to show their stuff, or maybe it was only five minutes to show their stuff.
Uh, I, I, so you’re definitely bringing it down a little bit, but what I found valuable was once they got into our cadence of having those discussions about how do we fit all six teams inside of this sprint review, they started talking about telling a story rather than just showing, “Here’s I added this feature to the product.”
Okay, but why did we add that feature? How does that fit into the story of what these six teams are trying to build?
And that started to then add more context, and so that it was even more targeted feedback on, “Well, we’ve built this part of the story. Maybe we need to focus on this part of the story next because then we can have a holistic view of what’s going on.”
It’s generally to elicit conversations. The more conversations you have, hopefully, the better the outcomes.
But that was demonstrating. Yes, it doesn’t say if you are time boxed, then you can always say at the end, “Now we covered off A, B, and C. If you want more information, you know where to find us.”
Yeah, so if someone is particularly interested in, I don’t know, you know, some example, then you should always have that as an open invitation.
Did you find that that happened a lot?
Uh, yeah, but we’re all on the same floor in one big building, so it wasn’t difficult. People would actually come and get you immediately afterwards if you’d said something that their areas pricked up on.
They wouldn’t dive deep into it then and there because they can be very expensive, but they will come and see you afterwards and say, “You weren’t going to shift this information. We actually only want a tiny amount. Could you actually prioritise that?”
That’s the sort of thing that people would say after that event.
You know, maybe even three or four scrum masters get together and try and work out exactly what we could deliver in terms of, you know, to the overall product if someone wanted to specific for some very, you know, high-value reason.
So that gets to that collecting feedback.
How are we going to collect feedback from people, especially when we’re in the virtual space?
Because most of us are operating almost 100% in that virtual world, and it’s even more difficult to get feedback from people.
You can’t just look at the person who you know has some feedback or see it as easily on their face if they don’t have their cameras on.
Um, so the two types of exercises that I’ve done with teams are one, two, four, all right?
So have them build lists. One, two, four, all is about building lists, and it’s one minute on their own creating a list, two minutes in pairs forming it in fours, and they merge those lists and then bring it back to the whole room.
So what are the ideas for what’s next?
Um, there’s also another exercise which is made up of three parts that I’ve used called a what, so what, now what?
Right?
And that’s quite an effective way to figure out what’s next.
So I’ve got both of those added to the mural as suggestions to go research and look at and see if it will do.
Both of them are part of liberating structures, so you can go to the liberating structures website and see that there.
Um, but, uh, what, so what, now what? I’ve had some really good experiences with it, not just in sprint reviews but in other areas as well. It’s quite a useful technique.
Oh, so collecting feedback, and it’s again, it’s the team and the product owner who are kind of hosting that.
And then maybe we need to review the business changes, right?
Maybe this is where, uh, not only do we have the product owner and the team providing input, but we’ve now got to bring the stakeholders in as well.
Oh, well, they’re providing from collecting feedback, but, um, they’re talking.
They are bringing, you’re saying to the stakeholders, “What’s changed in your part of the business that you think matters to what we’re building?”
Has do is what you need changed?
Right?
Because if you build stuff that people don’t need, they’re not going to provide you with feedback.
They’re not going to care about what you’re creating.
What do those people need, right?
And what do they need next? What’s the most valuable thing we can do for them?
And now what?
So what now? What can definitely work in that space as well?
Um, and maybe those two activities you might roll into one, collecting feedback and business changes and having those discussions.
Um, but I just wanted to be clear that we need to make sure we cover both of those topics.
And then we need to actually review and update the product backlog.
So I would potentially crack open the product backlog, show everybody what’s at the top of the product backlog, and are these still things we need?
Right?
Some of them might be technical needs because the team needs to do them in order for other things to happen, but we can have those conversations.
I don’t want a stakeholder going home fuming, “Why am I not getting the thing I want? I thought it was more important than this other thing.”
But actually, this other thing is a prerequisite of the thing they want. If they don’t understand that, they’re going to be pissed, right?
Because they’re not getting their thing.
I normally publish the draft, um, sprint backlog for the next sprint and maybe even do it prior to the meeting so it’s actually circulated in advance.
Uh, that way people can turn up with a pre-prepared opinion.
That is definitely a good way to prepare people if you have that information.
Have a draft of the goal. What do you think? What does your product owner think the goal is going to be for the next sprint?
What are the things that they think in collaboration with the team are going to be part of that story?
Because they should have had those conversations during refinement.
Right?
Oh yes, so Carlos, the one, two, four, all is you have one minute for people to write stuff down on their own, two minutes in pairs, and then you join two of the pairs together and they get four minutes in effectively two pairs and then bring it back to the whole room.
And it’s a way to get even the most introverted people part of the conversation and contributing to the story.
Definitely gets people out of their shell. You can find it on the liberating structures website.
Um, but I run that, I use that judiciously in the live virtual classroom space for sure. It’s a really good way to break that up and stop people feeling like meetings and events suck because it’s just, you know, broadcast.
It’s collaborating on what to do next.
Um, and then the last thing I’ve got is perhaps reviewing timelines and budgets for the next release.
Right? We’re spending the customers’ money.
We’re spending the businesses’ money. They kind of want to know how, how are we spending it?
And I would rather do that in an open and transparent public space with all of the stakeholders that care about that stuff than the product owner having ten private conversations with a group of people having to justify themselves ten different times, maybe in ten different ways.
Right?
Don’t let your product owner be browbeat, browbeaten, I think is the expression, by the stakeholders because they get them alone in a room.
Right?
Have these discussions open and transparent.
Let’s let the stakeholders browbeat each other rather than the product owner. That’s the way I look at it.
And at the end of the event, we’ve updated the product backlog.
We physically updated it. We’ve made changes to it. We’ve changed the order. We’ve added new things. We’ve deleted things.
To me, that sounds like quite a lot to happen in two hours. Sounds like I might struggle for time, right?
So maybe we can’t cover everything every sprint review, but what’s the important things to cover, especially if you’ve got big teams off, right?
And that science fair model works really well where people just see the ones they care about.
Uh, it was a question.
Yeah.
So somebody’s asking what happens if I don’t get everything done for a piece of value?
And I would say that piece of value is not done.
And if you show stakeholders something that is half-finished or even 90% finished, they’re not going to be happy.
And if you try and claim that it’s finished, like show them something as if it’s finished, it’s not really morally or ethically sound.
I, we’re basically saying we finished this.
Don’t tell them we haven’t finished those four things that need to be done and we’ll do them tomorrow because they might get forgotten or the world might have changed tomorrow and we need to do something different, right?
And that thing never gets done.
Don’t get caught lying to your stakeholders.
Open and transparent is kind of the key there.
And even if it’s small, like, like, uh, in Magda’s version, if even if it’s just a little bit negative all the time, that can build up to that death of a thousand cuts for a team and end up in that spiral of negativity.
Um, trying to bring it down to what’s the smallest thing we can deliver.
If we feel like we’re never meeting our sprint goals, we’re probably taking on too much work, right?
Or we’ve got the wrong sprint goals. Fix those things.
Create a virtuous cycle supporting the team and what it is they’re trying to do, and hopefully we’ll build more awesome stuff and less sucky stuff.
That’s what we’d like to see.
Are there any highlights?
Uh, maybe I want to, uh, ask about something in here. I mean, like, it’s in my mind. It’s, uh, like plus and minus persons because, uh, about the criticism.
Uh, what do you think about it? Like, uh, is the criticism is a kind of feedback through or is it just negative?
So there’s constructive feedback that is negative about what it is we did.
And then those, um, was that Carlos or Andre?
Andre that was asking the question.
Andre, um, that question sucks and I don’t like the way you said it.
Okay, that’s not constructive feedback, right?
Right, yeah.
So it’s if you think of the scrum values, we want to be openness, right? And courage to say that things are wrong, but respectful.
I don’t know, we see it, and it’s not respectful to have some hippo in the room saying to the team that you suck and everything you did sucks, and your products suck.
You know, that’s not to create a positive response in anybody.
So part of the role of the scrum master is helping everybody interacting with the scrum team understand what interactions are helpful and what aren’t as well.
So maybe if that person who’s like that is going to be participating, maybe the scrum master needs to go maybe coach them and help them understand how do we create positive interactions, not negative interactions.
And you can be critical, positive in a positive way, right?
And it’s about the way we speak to people, the language we use. It is really important, and it’s culturally specific as well, right?
So what works in, when I’m teaching classes, what works in Saudi Arabia doesn’t work in the UK, it doesn’t work in Norway, right?
So you need to take that into account, who is attending your meeting and what is their culture, even within different companies.
And then the last one, number four. I don’t know why I ordered them in that weird way, but there we go.
Uh, sprint review has the highest number of participants, making it an expensive event.
Okay, so this time, all of these statements are in fact true, and the sprint review is usually your most expensive event.
Right? You’ve got two hours, you’ve got the scrum team, so the product owner, the developers, and the scrum master, and a whole bunch of stakeholders, business people, people who care about your product.
The most people at any time are in that event, therefore it is, by definition, the most expensive event you have.
So you want it to be valuable, right? If you’re wasting people’s time, you’ll find that participation will decrease over time because people will stop coming back.
If you don’t show people anything they care about, they’re not going to come back next time, right?
Even if you don’t show them anything they care about, if they’re not engaged and don’t see anything they care about, they’re definitely not coming back.
So we need to figure out how do we encourage people to participate in that event.
Does that sound reasonable for my answers? Reasonable? Anyone to disagree with anything?
Oh, I got a little heart pop up there. That’s pretty good.
Using the tool.
Using the tools.
Um, okay, so let’s look at what a sprint review might look like.
Okay, so I’ve got a couple of pieces that I want to talk about here, and then I’ve got some little exercises around it.
So the first piece to think about is what’s the purpose of the sprint review in scrum?
Peter, I know I’m putting you on the spot, but what do you think the purpose of the review is?
Feedback.
Right, it’s part of our empirical process control system, which scrum is trying to implement.
And empiricism just means feedback. It means look at what happened and figure out what to do differently next to make what happened better the next time around.
Like that, those empirical feedback loops, inspect and adapt, all different ways of saying the same thing.
So the sprint review’s outcome should be an understanding of what we are doing next.
And in scrum, we store that information in an artifact to provide transparency called the product backlog.
Right? That’s where we’re transparently reflecting what are we going to go do next, what’s the next most important thing to do, what’s coming up after that, right?
That’s where we’re reflecting that.
So we need to walk out of the sprint review with an updated product backlog.
Uh, yeah, I can put, uh, could you put the link for the mural in the chat? Just copy it from where you’re talking.
And you have one more question in the chat as well.
I haven’t had that. It says, can you like, what happens? So Carlos is asking what happens when the product owner is absent in the sprint review? Could you share your opinion on that, please?
That is a very good question. I am going to share it with a little story. I worked with an organization in Horton, which is about, I don’t know, it’s about two hours south of Oslo, I think it is. Two hours southern, one hour, two hours would train, one hour, yeah.
I always went on the train, so it was two hours.
Um, and I had, I worked with this team and they were very, I’m actually going to say depressed, right? They were not a happy team.
Um, they had a very negative outlook on the work they were doing and what they were doing, and I was trying to figure out what the problem was.
Right? So I go to the sprint, the events and see what’s going on, and at the sprint review, I just asked them, I didn’t see anybody new, so I was like, “Who’s the product owner?”
“Oh, oh, that’s Thor, right? He’s not here.”
Like, is this, is he usually here?
“I don’t know, he doesn’t normally come to the sprint reviews.”
How would you feel as a team if your product owner thought so little of the work that you were doing that they couldn’t even be bothered to come and see what it was you did and how well it was done?
How would that make you feel?
Probably make you feel like nobody values your work.
[Music]
Right?
What are the three things that we need to feel like we can work well as from at Drive Dan Pink’s book Drive?
Let me remember what the three things were.
It was autonomy, mastery, and purpose.
With the three intrinsic motivations, once you get money off the table, when we’re not worried about putting a roof over our head, autonomy, mastery, and purpose.
We want to feel like we’re in control of the work we do, right?
So scrum facilitates that with our self-organising teams selecting the work at sprint planning.
We want to feel like we’re good at our job, right? That we’re learning more things, mastery of our profession, right?
And that manifests both in professional scrum, right? We’re doing that part well, but also engineering excellence.
If you’re a software team, you know, are we doing DevOps practices? Are we getting value from our product? Are we continually shipping it to production? Are we always increasing quality? Are we learning from each other?
That’s that mastery.
And then purpose. Are we building stuff that matters?
Do we feel like the stuff we build matters to other people? Because otherwise, why do I get out of bed in the morning if what I do doesn’t matter?
Okay, well, I won’t do it then, and we’ll have the same outcome.
So how do you create that purpose for people?
And the product owner turning up to the sprint review is probably one of the first steps.
If you can’t get the product owner in, you probably can’t get the stakeholders in either.
And isn’t he supposed to get them in at least on the, that’s one of his jobs as well, to get them together to showcase what’s happening?
And part of the problem I found for this team was that the product owner also wasn’t doing the product backlog.
Therefore, the team was building stuff that the product owner didn’t care about because the product owner didn’t care what they were working on enough to go update the product backlog and tell them what to work on.
Right?
So it was one of those vicious cycles of spiralling down to mediocrity.
And the question is, what was he actually doing to have the title product owner?
Sounds like he was not doing anything.
So, but this is where we get to that difference between do I have the job title of product owner or am I fulfilling the accountabilities of being a product owner?
And I don’t really care about the job title part. You can be called a delivery manager, you can be called a product manager, you can be called a project manager, right?
I don’t care what your job title is.
But somebody needs to take the accountabilities of the product owner, um, which is making sure that there’s a clear, transparent product backlog that reflects transparency of the future that, um, everybody on the team and the stakeholders understand what those things are and then actively managing that going forward into the future.
So if those things aren’t happening, that’s where I would look. Who’s supposed to be doing that?
So another question in the chat there. How do you get outcomes from the user?
Could you recommend some tips?
Now, I’m not sure I understand outcomes from the user, so maybe you need to explain a little bit better, but I think I might answer that question as we go through.
Okay, how do we get feedback from the user maybe?
Um, or maybe it could also be that you’re asking how do we know what the outcome’s supposed to be rather than just being given solutions, which quite often users try and give us solutions.
So I’m not sure what you mean there, Carlos.
Andre is asking an interesting question as well.
But can the scrum master be asked to back up the product owner in their absence?
Right?
And I would ask the question, if a product owner is doing their job right, they are taking those accountabilities, then they should be knowing what’s happening in the marketplace, what’s happening inside of the business.
Uh, they have relationships and manage relationships with stakeholders, whether difficult stakeholders, negative stakeholders, they still need to manage those relationships.
And they take all of that information of what the team wants to do, what the technical realities of the product is, what the business needs are, what the commercial realities are, and they funnel all of that information into here’s what we’re going to do next.
I’m not sure that I have often seen scrum masters that have the knowledge and skills to do that, right?
So it’s like in a different set of experiences.
I’m not saying it can’t happen, right?
But I would probably prefer a business analyst to be back up for the PO because they’re going to have a better understanding of what the business needs than the scrum master might have.
Or maybe the scrum master is your business analyst, in which case maybe yes, right?
There’s no real rule around that.
Ah, so Carlos is asking how do we measure the outcomes?
Um, let me kind of, let me put a pin in that and you ask that in a little bit, okay?
Um, because I think we might get to that.
Um, so what do you think we need going into a sprint review?
What’s, what’s, I mentioned a couple of things as part of this funnel, right?
One of the things that the product owner needs to bring into that story in order to be able to review, discover, and rearrange the product backlog to reflect transparency in the future.
What should we show? What should we have on here?
You have the sprint goal from the last sprint, so that’s what you should be measuring yourself against.
Because maybe we’re measuring our, yep, we are likely measuring ourselves against did we achieve the thing that we committed to?
Yeah.
What else is important in this product strategy?
Giving us the direction where we want to go so we can align flex strategy.
Yeah, absolutely. What’s our overall strategy?
I would suggest that might be a combination of the product vision and maybe the current product goal, right?
But maybe there’s more information there, so I’m happy to put all of those things on the list.
There’s probably useful information.
What else?
Remember, your product owner is spending the money.
They’re deciding what we’re going to go work on.
So what do we need to discuss in order to try and be as right as possible at this point in time in what we’re building next?
So the value of the product backlog items.
Yeah.
The value contained within the product backlog.
What about we just did this two weeks ago?
Let’s say we’re doing two-week sprints.
We just, we’re doing two-week sprints two weeks ago.
Um, what’s changed in the last two weeks?
You’ve discovered more.
Ace or later wants you to inspect the outcome in the chat.
Yeah, so the, the, I’m, what is the outcome? What’s the result of all of our work?
The increment.
Yeah, we need to inspect the increment.
The product has changed in the last two weeks.
Maybe that means some of the stuff that’s on our backlog we don’t need.
Maybe that means that there’s other stuff we do need because of whatever we built.
Right?
But there’s also changes in the business, right?
What’s happened in the business in the last two weeks?
Is their needs and desires exactly the same as they were two weeks ago?
Isn’t that part of just having the backlog always ordered according to what’s required or what’s the changing tide in the business?
So this is the moment where we have all of those stakeholders as well as the team together.
So you mean more reordering the backlog based on what has changed, not because if there’s a change for it, because otherwise I would expect that to be always present in order backlog.
So maybe there’s a change that the product owner knows about, but maybe there’s a change that they don’t.
Yeah.
What’s happened in the business?
And then perhaps market changes.
If you’re building a commercial product, what’s, what have competitors been doing?
Right?
Maybe that’s going to impact how our priorities have changed, right?
What do you think happened in the sprint first sprint review at the Microsoft Teams when lockdown happened?
Right?
We need the world’s changed.
We need to throw out this backlog and what do we need now?
What’s the most important thing we can do to help solve our users’ problems now, which might be completely different from two weeks ago, right?
I would argue that is a massive change that you don’t want to wait for the sprint reviews.
I would definitely agree.
Probably it requires a special session and something bigger happen.
Yeah.
I used a massive example, which definitely I would agree or would probably have some special things happening.
Um, but what’s happening in the market?
What competitors are releasing?
Maybe they’ve released a feature that means that users are starting to gravitate towards your competitors rather than your product.
How do you get ahead of that?
Headed off and do that.
So we’re going to take all of that information, present it in some way, and bring it into everybody’s consciousness, their frontal lobe, so we can noodle on it and have discussions about it.
So we don’t just need stakeholders, but we need the right stakeholders for the conversations that we need to have.
So you’re right, the product owner probably needs to have some understanding of what do I want to discuss walking into the sprint review so I can invite some of the right stakeholders.
Right?
Some stakeholders are going to come every sprint because you’re building stuff they care about, so they want to provide you with feedback.
So stakeholders is kind of a catch-all word that they use in scrum, which just means anybody who cares about the outcomes that the team’s working on.
Right?
So they could be users, could be business people, could be purchasers, could be anybody.
I worked with a company in the UK, and they ended up having to, they had one of those, um, like all hands meeting rooms in their company headquarters, and they would fill that for a sprint review.
They’d be hard pushed to fit the hundred people that turned up to see their sprint reviews.
Right?
But it took them months of what do you really want?
And once you start building things that people want, they’ll want to come and provide you with feedback.
Right?
They don’t want to provide you feedback on stuff they don’t care about.
So maybe share the goal, and then does everybody remember what the sprint goal was last sprint?
Perhaps not, so we need to share that as well, and again that would be the product owner sharing that.
And then maybe in some way we want to demonstrate the working software.
Who’s best placed to demonstrate the working software?
With the team, wouldn’t it?
They’re the ones who just built it.
They should be able to explain to the stakeholders what it is they’ve done and why it matters to the stakeholders.
We’re building value after all, not features.
Right?
Nobody really cares about user stories and features; they care about value.
What do I get from what you’ve just added? Tell some stories.
Right?
That’s the way I, I, I, storytelling is the best way to do that.
Um, so there’s a number of techniques that I’ve seen work really well in demonstrating the software, um, depending on how many, if you’ve just got one team, right, doing a presentation, maybe they just present, “Here’s what we changed,” right?
If you’ve got ten teams, that might take too much time.
So, uh, maybe you need something that looks more like, uh, have you seen in those American movies when the kids have their science fair at the school?
And you’ve got a bunch of stations, each presenting a different thing, and people go to the things they care about?
That’s the science fair model, and that can be implemented virtually as well with breakout rooms, and there’s various techniques for that.
Um, but doing that might be good.
Uh, doing some kind of shift and share if you’ve got a lot of stakeholders.
Shift and share is when you send people out to breakout rooms, and each breakout room is a particular feature or part of the product that one of the teams has been working on, and then you have the attendees move to the next room, the next room, the next room.
Uh, in order to facilitate that, I’ve done that one in Teams, um, and it works in Zoom as well.
But how many teams should a sprint review have? Shouldn’t it be per team kind or rent review per product?
So if you have ten teams working on one product, you show one unified working increment to the stakeholders because you’ve only got one product.
So we’re doing a review of the increment, and we have one increment.
We don’t, ten teams working on the same product don’t create ten different increments because then that’s not integrated together.
Therefore, it wouldn’t meet a definition of done.
And that sounds good.
So what a lot of teams do, or what a lot of product management does, is they create some kind of alignment in their product to minimize the number of people that are part of each of these stories.
Right?
So if you look at the way, and the example I always use examples from the Azure DevOps team because I’ve been working with them for a long time, but they all over the part of the eight years of their transition towards agility was they shifted their product from one big ball of string, right, to almost like verticals of here’s a, and it’s now called Azure Boards, right?
The graphical representation of the work that you’re doing.
So there’s one product owner for one product, and then that product owner maybe has two or three teams working for them, and those two or three teams are contributing to that single unified product.
So you have one backlog, one product owner, one maybe one sprint planning or like a pre-planning and one sprint review.
Yeah, but would you do one sprint review for all five products in that?
If I had five products, different products, I would maybe have five different reviews.
Yes.
Yeah, but your Azure DevOps is now becoming a mixed sample or mixed example because now they’re five different products, which each of them, so at the small scale, right, there is only one right answer: one product, one product backlog, one product owner.
Right?
But once you scale up to larger interconnected systems, maybe some of those systems are their own products that can be shaped on their own.
But I would suggest if it ships together, it needs to be reviewed together.
Right?
So if you have a product where you’re breaking it up by component rather than by vertical value streams, then you probably need, you probably forced into the larger review where you’ve got one bigger product.
And now when you do have a much larger review, something the Azure DevOps team did do was prior to their sprint review, every team would create a video to present the demo of what it was they created and send that out to everybody.
So it’s been my experience for the big projects or big programmes to do one demo for the whole project product, however you want to describe it.
Um, and at one level, you could say, “Well, I was looking after data migration. Did I really care that much about the user experience at the other end of the data flow?”
But it was still useful to hear someone say, “What we want to see next sprint is we want to see the events.”
So then that would actually inform me why people were then chasing me to migrate events from the database through the entire value chain.
So even though I normally didn’t care, it actually provided me and my team with some useful feedback.
Um, they, we can’t load this data, whatever x, y, and z data, so we’re not going to display in the UX for another couple of weeks.
So that would inform the guys at the other end of the flow, “Well, let’s not plan any work around trying to get that data in because the migration team aren’t going to get it to us for a few sprints.”
So it is useful for everyone to hear at least five or ten minutes what everyone else is trying to achieve.
Yeah, the other teams are also stakeholders to your input or output.
Maybe some of those teams are providing output that is your input, right?
And maybe you’re providing output that is their input. They’re blocked from delivering some features until you’ve got something there for them.
Right?
So it’s that whole context that is important in the demonstration.
And so I do agree that there are scale issues, and you have to figure out what practices work.
Uh, the Nexus framework, which is scrum.org’s scaling framework, encourages having a single sprint review, but it does talk about it being for up to nine to ten teams working together.
If you get more than that, you probably want to spread it into, I think they have a, I can’t remember what the phrase is, but it’s Nexus of Nexus.
Right? You might have multiple nexi, uh, that roll up to a single product.
It’s just more complicated, and the example that I think sits well with what you’re talking about over is I think about the Office team, right?
The Office team, SharePoint is not really that dependent upon Word, but Word exists also as a separate app but also inside of SharePoint.
So maybe there is a lot of crossover, um, but they’ve got nine hundred people-ish working on that product.
Um, so how might they organise that to be, to get the information to the people that need it, the feedback from the people that need to provide that feedback?
Um, it’s figuring out what works at scale.
There are no hard rules at scale; there’s so many different options there.
Yeah, I’m just seeing some, you said it was up to four hours.
Yeah, I know it’s just a number, but up to four hours for a one-month sprint, and you should be able to fill it.
But then if you are done, three teams, are you at twelve hours then?
No, it’s still one sprint.
So what I’ve seen work, and actually what one of the teams that Peter was working with, um, they had a tight time box inside the sprint.
Maybe each day, I think there were six teams, and maybe each team gets seven minutes to show their stuff, or maybe it was only five minutes to show their stuff.
Uh, I, I, so you’re definitely bringing it down a little bit, but what I found valuable was once they got into our cadence of having those discussions about how do we fit all six teams inside of this sprint review, they started talking about telling a story rather than just showing, “Here’s I added this feature to the product.”
Okay, but why did we add that feature? How does that fit into the story of what these six teams are trying to build?
And that started to then add more context, and so that it was even more targeted feedback on, “Well, we’ve built this part of the story. Maybe we need to focus on this part of the story next because then we can have a holistic view of what’s going on.”
It’s generally to elicit conversations. The more conversations you have, hopefully, the better the outcomes.
But that was demonstrating. Yes, it doesn’t say if you are time boxed, then you can always say at the end, “Now we covered off A, B, and C. If you want more information, you know where to find us.”
Yeah, so if someone is particularly interested in, I don’t know, you know, some example, then you should always have that as an open invitation.
Did you find that that happened a lot?
Uh, yeah, but we’re all on the same floor in one big building, so it wasn’t difficult. People would actually come and get you immediately afterwards if you’d said something that their areas pricked up on.
They wouldn’t dive deep into it then and there because they can be very expensive, but they will come and see you afterwards and say, “You weren’t going to shift this information. We actually only want a tiny amount. Could you actually prioritise that?”
That’s the sort of thing that people would say after that event.
You know, maybe even three or four scrum masters get together and try and work out exactly what we could deliver in terms of, you know, to the overall product if someone wanted to specific for some very, you know, high-value reason.
So that gets to that collecting feedback.
How are we going to collect feedback from people, especially when we’re in the virtual space?
Because most of us are operating almost 100% in that virtual world, and it’s even more difficult to get feedback from people.
You can’t just look at the person who you know has some feedback or see it as easily on their face if they don’t have their cameras on.
Um, so the two types of exercises that I’ve done with teams are one, two, four, all right?
So have them build lists. One, two, four, all is about building lists, and it’s one minute on their own creating a list, two minutes in pairs forming it in fours, and they merge those lists and then bring it back to the whole room.
So what are the ideas for what’s next?
Um, there’s also another exercise which is made up of three parts that I’ve used called a what, so what, now what?
Right?
And that’s quite an effective way to figure out what’s next.
So I’ve got both of those added to the mural as suggestions to go research and look at and see if it will do.
Both of them are part of liberating structures, so you can go to the liberating structures website and see that there.
Um, but, uh, what, so what, now what? I’ve had some really good experiences with it, not just in sprint reviews but in other areas as well. It’s quite a useful technique.
Oh, so collecting feedback, and it’s again, it’s the team and the product owner who are kind of hosting that.
And then maybe we need to review the business changes, right?
Maybe this is where, uh, not only do we have the product owner and the team providing input, but we’ve now got to bring the stakeholders in as well.
Oh, well, they’re providing from collecting feedback, but, um, they’re talking.
They are bringing, you’re saying to the stakeholders, “What’s changed in your part of the business that you think matters to what we’re building?”
Has do is what you need changed?
Right?
Because if you build stuff that people don’t need, they’re not going to provide you with feedback.
They’re not going to care about what you’re creating.
What do those people need, right?
And what do they need next? What’s the most valuable thing we can do for them?
And now what?
So what now? What can definitely work in that space as well?
Um, and maybe those two activities you might roll into one, collecting feedback and business changes and having those discussions.
Um, but I just wanted to be clear that we need to make sure we cover both of those topics.
And then we need to actually review and update the product backlog.
So I would potentially crack open the product backlog, show everybody what’s at the top of the product backlog, and are these still things we need?
Right?
Some of them might be technical needs because the team needs to do them in order for other things to happen, but we can have those conversations.
I don’t want a stakeholder going home fuming, “Why am I not getting the thing I want? I thought it was more important than this other thing.”
But actually, this other thing is a prerequisite of the thing they want. If they don’t understand that, they’re going to be pissed, right?
Because they’re not getting their thing.
I normally publish the draft, um, sprint backlog for the next sprint and maybe even do it prior to the meeting so it’s actually circulated in advance.
Uh, that way people can turn up with a pre-prepared opinion.
That is definitely a good way to prepare people if you have that information.
Have a draft of the goal. What do you think? What does your product owner think the goal is going to be for the next sprint?
What are the things that they think in collaboration with the team are going to be part of that story?
Because they should have had those conversations during refinement.
Right?
Oh yes, so Carlos, the one, two, four, all is you have one minute for people to write stuff down on their own, two minutes in pairs, and then you join two of the pairs together and they get four minutes in effectively two pairs and then bring it back to the whole room.
And it’s a way to get even the most introverted people part of the conversation and contributing to the story.
Definitely gets people out of their shell. You can find it on the liberating structures website.
Um, but I run that, I use that judiciously in the live virtual classroom space for sure. It’s a really good way to break that up and stop
