Are you going to try any of those tips? Which one is your favourite tip? I'd love to hear your thoughts on this! Or perhaps you have your own tips on how to improve sprint reviews and getting more effective feedback and learning from them? Let me know in the comments below!
@SomeshwarKoshti3 жыл бұрын
Address Discovery and not just delivery
@EdWagener3 жыл бұрын
When will you do the video of pt.3 Time between sprint?
@TheAgileBroadcast3 жыл бұрын
Hi Ed, I wasn't planning on making one, but now that you mention it, I'm thinking "why not"! This would be great topic to address in more details - watch this space 😁
@RamAliSinghJoseph1429 Жыл бұрын
Time between Sprints seems like an interesting concept
@TheAgileBroadcast Жыл бұрын
The whole point is to address discovery/validation and not just delivery. One way could be to take more time after delivery to validate things... BUT, we also want a continuous (sustainable) pace of development. Best IMO would be to integrate that within the sprint itself
@AmNotLegend2 ай бұрын
presenting both delivery and discovery, and then showing direction for the next sprint
@Metalblowing Жыл бұрын
Just moved to a PO role from an implementation consultant. I have ton of product knowledge but 0 understanding about the process. This was helpful. Thank you.
@Bart1343 жыл бұрын
Discovery process is the first one we are going to implement. It also shows that we as a team don't know everything and we need your feedback!
@BBsheepy2 жыл бұрын
Amazing you wrote backwards!!! I love these points, we put in ticket for self direct time! And dev can do whatever they want in those hours or days
@adivax33 жыл бұрын
This is a great video...awesome tips and I will be having a discussion with my squad today, as I want to implement each tip you reviewed.
@ptiwarivideos5 ай бұрын
Great tips. I have these tips in mind already, but real time needs PO involvement.
@husnaink4 жыл бұрын
Would wait for your Agile manifesto … Sustainable development video. Great tips
@TheAgileBroadcast4 жыл бұрын
Sustainability is a great and important topic. There might be a video on this in the future. Watch this space!
@czarcoma6 ай бұрын
If we're going to evaluate if the increment actually provided value, the Sprint Review needs to happen after release? It's only then can the business stakeholders provide feedback based on the actual experience of the end users.
@TheAgileBroadcast5 ай бұрын
The whole idea of sprinting is to release at every sprint at a minimum... So yes!
@garagavia3 жыл бұрын
Don't tell me your tips are amazing up top. Give me the tips and I will find out if they are amazing. There you go, some feedback ;)
@faithomisola63933 жыл бұрын
You talked about making the PO own the sprint review as opposed to the dev team which I think is a great idea, but how do you make the PO own the sprint review? Do you tell him that we are having a sprint review and I want you to be the main person running or facilitating it? I know my question might sound crazy but like I said, Some things in agile are still vague to me and i'm just trying to understand better. Would love if you can shed more light on this and also make more videos about running meetings. Thank you!!!
@TheAgileBroadcast3 жыл бұрын
Making more videos on how to run meetings is great idea, thank you 👍
@TheAgileBroadcast3 жыл бұрын
For the PO running the review, I wouldn't just impose this... I would probably bring it up at a retrospective and suggest it. The whole team should be on board with the idea. The point is to move away from the sprint review being just a demo... A demo doesn't really foster collaboration or feedback. It's too easy to just nod and wait for the next big release... The PO might well be reluctant to accept this. They might say "hey, I cannot do this, I don't know how the feature works since I haven't seen it yet"... But that's the whole point. The feedback then would be much more relevant. The team can also just observe how the PO struggles.. that tends to reveal a lot of interesting points!
@faithomisola63933 жыл бұрын
@@TheAgileBroadcast Thank you for the reply. I really love your videos!!!
@TheAgileBroadcast3 жыл бұрын
Thanks for the kind words!! Much appreciated 😁
@thealigators88153 жыл бұрын
Please what are you writing on and how is it positioned. It feels like I am in the classroom watching you write on the board.
@TheAgileBroadcast3 жыл бұрын
Making you feel like you're in the classroom is the intension! It takes a little bit of setup to accomplish, but it's basically just a plexiglass screen in front of me.
@thealigators88153 жыл бұрын
@@TheAgileBroadcast Thank you for your quick reply. One more question please where is your camera positioned? in front of you or behind?
@TheAgileBroadcast3 жыл бұрын
Camera is in front me. Screen is between me and the camera.
@dorianthreethousand26242 жыл бұрын
The third tip is good, but no necessary if the team is "working in Sprints at a sustainable pace" like it is written in the Scrum Guide 2020.
@TheAgileBroadcast2 жыл бұрын
Hey, apologies for the late response! Somehow missed your comment before... I think it's more a matter of understanding the need to validate what you build rather than having a sustainable pace. Having said that, who is to say that sprints are only for delivery and not for discovery or validation...
@NERIDA822 жыл бұрын
Great video and very helpful! What do you think of Scrum Masters preparing a Power Point presentation with charts like velocity, throughput, bugs, satisfaction, tasks completed and tasks to be completed, and then ask PO and Developers to add something? I do not agree, btw. I think this is not providing value, but showing something that can be easily consulted on Jira board. But I am open to look at other opinions.
@TheAgileBroadcast2 жыл бұрын
Yeah, it's not something I do nor recommend... These can be useful input for the team itself, maybe for a retro for example (especially with the metrics for flow like velocity, throughput, etc.) Showing tasks completed/not completed is also not the right thing to do at a sprint review IMO. When people do that, it shows a mindset based on output rather than outcome (I have another video on that if you want to check it out?) The review is about the product, not about the management of the "project".
@NERIDA822 жыл бұрын
@@TheAgileBroadcast I completely agree with you! The value is the goal of Scrum. So if there is no "demo" (even if it is bad to call it this way) do the team proceed by showing Jira tasks (something I have seen from others) or what? Any thoughts? Your content is amazing!
@TheAgileBroadcast2 жыл бұрын
@@NERIDA82 thanks for the kind words! When you say "no demo", is that because the sprint goal is not reached for instance and no value can actually be demonstrated? If that's the case, then why have a review? The sprint has failed, right? Let's not waste the stakeholders time. People are reluctant to do this because "it looks bad"... it's tough because people might say "well, it's not like we didn't do anything!" and they would probably be right! But the point is not being busy, and showing jira tickets progress via ppt and no valueable stuff to demo only demonstrates the busyness... ... which in turns points at the culture of the organisation. If there is such a pressure (external from managers as well as internal from people's own mindset) to basically beg for forgiveness i.e. "believe us, we know we failed this sprint, but it's not because we are lazy"... then we have another problem, much bigger than agile!
@NERIDA822 жыл бұрын
@@TheAgileBroadcast no David, "no demo" is because remote team is working on data (no software to show). They choose to show a pp with screenshot of the tickets from Jira (done work, remaining work, what planned for the next sprint, and what they plan to do). On the contrary, I am the one who prefers to focus on what value a feature has brought, which challenges the team has solved. I want their feedback to improve. Do you think my approach is correct? In this case, do you show Jira tickets or what? How do you plan your sprint review in terms of tools? Thanks for your kindness in claryfing. I always ask myself questions.
@TheAgileBroadcast2 жыл бұрын
@@NERIDA82 Yes I think you have the right approach. Focusing on value, challenges and getting feedback is the most important thing. How to plan the review in terms of tools? Not sure what you mean by tools... There is no need for tools IMO. I might use a ppt to show a couple of slides to show the sprint goal and user data (e.g. if we've released a feature in previous sprints, then it's to show data about the usage of that feature - are people using it at all? Or for instance, if the goal of the feature was to get users to do something, well, let's check that they actually do). And you can also show an outlook of what's coming next (not in the form of Jira tickets, but in the form of a customer-centric sprint goal) Your team is working on data you say? So perhaps, they don't deliver features to users directly, which makes things trickier. But... they still have a customer - maybe other teams, who are going to use that data. The review is for them. And if the data is used by other software development teams that build feature... why not combine the sprint review is those other teams once the feature that uses the data is complete? And final thought... having a data team sounds like a bad idea to begin with to be honest. Scrum promotes the idea of cross-functional team, i.e. a team that has all the skills necessary to bring value. But data is often just a piece of the puzzle, right? If they deliver just a piece and you need lots of other pieces before you see user value, then it's going hard to be agile with a such a team setup. Hope this helps?
@vivekpjadhav3 жыл бұрын
how do you guys write backwords or its just look like that ?
@TheAgileBroadcast3 жыл бұрын
Magic 😃
@TheProjectBoss Жыл бұрын
How are you able to write on the screen?
@TheAgileBroadcast Жыл бұрын
It's called a lightboard. You simply write on a glass screen placed in front of you. That means the text is back to front of course... So you then need to flip the image with a video editing software, and that's that
@b.a9891 Жыл бұрын
Your tip 2 is not that optimal because you are working from a bias standpoint assuming that is either po or dev should be leading or owning the meeting . Having the po host a meeting and presenting with their teams (that could be co-organized together ) could be an alternative , there are so many unexplored options here . the idea of having only one person owning the meeting is really full of flaws .. and besides what does owning meaning ? Does it or mean being the only person talking ?presenting ?Maybe start with defining the owning word generate the use cases of interacting emanating from that and then maybe creating delegation levels based on those uses cases between the po and the devs (don’t like the word dev team because you are creating a subteam paradigm mentality by saying that ) .I think this binary thinking is not optimal in complex env ..
@TheAgileBroadcast Жыл бұрын
Thanks for your feedback! Though I think what you present is a bit of a strawman. Maybe you think the entire concept of a PO role could/should be removed (and I wouldn't necessarily disagree there 😜) but a PO is by definition a single person and is meant to, quite literally, own the product. I see too many teams presenting the output of what they've done and the PO passively listening... In those cases, I want the PO to be in the driver seat (and yes, even better if they do that together with the rest of the team). Being in the driver seat doesn't mean you're the only one talking, or presenting... Just use your imagination when trying to get a passive PO into being more actively engaged with reviewing the product. Making the PO the driver is, I found, a good way to radically change the dynamic of the review from output to outcome. Now, do we want this original imbalance to be simply reversed (so now the Devs are passive)? Of course not. So I agree with you, even better to build a team with no barrier product/business/developer... That's a far away dream for most teams... Which is why this is just a "tip", not a recipe of "how to do things".
@h.t.73102 жыл бұрын
Remove your image you loom too tired. Get some sleep man before going on air. Can’t watch.
@TheAgileBroadcast2 жыл бұрын
Sorry to hear you feel so strongly about how I look... Do you have feedback related to the actual content?
@h.t.73102 жыл бұрын
@@TheAgileBroadcast excellent production you just look ssooo tired! Then I get feeling the same way….so it’s hard. Will comment when I watch. So I have to mention this…But related to UX. UX produce red videos go on an on about usability then don’t us e UX principles in video, like one the content is perfect but the portraits shots with shiny skin reflecting light, then really bad hair, I almost felt sick.With Krug of Rocket Surgery fame video on UX was so bad I think I told him he needed a Razzy award. What happens you look so tired you can’t even focus on the content.it’s such a distraction. But the lighting, and production values is high. Bad UX on videos can render the video unusable.
@RamAliSinghJoseph1429 Жыл бұрын
Excellent video. And you worked so hard on the content so applause for you. Work is more important than looks .....
@RamAliSinghJoseph1429 Жыл бұрын
@h.t.7310 i think we r here for content not looks..... do u agree