🥅 Improve Your Scrum Team's Sprint Goal With These Simple Guidelines ...

Рет қаралды 3,595

Жыл бұрын

The Sprint Goal can affect how the Sprint is run. However, there are quite many organisations who still have a misperception that the Sprint is only a mini-waterfall and the Sprint Goal is about finishing all of the Product Backlog items that has been prescribed. In this video, I share with you my simple guideline to create an outcome driven Sprint Goal.
#scrum #productmanagement #agile

Пікірлер: 19

@lifeafterforty Жыл бұрын

Thanks Josh. Learning a lot from you from every single video you post!

@scrummasterinblack Жыл бұрын

Thank you for the support @Poonam 🙏

@biplab43 Жыл бұрын

Out of many, this is now my fav video explaining Sprint Goal. Right on the spot :)

@scrummasterinblack Жыл бұрын

Thank you @Biplap 🙏

@MarkBurville Жыл бұрын

Awesome template for Outcome orientated Sprint Goals, thanks Joshua 🙏

@scrummasterinblack Жыл бұрын

Thank you @Marco :)

@TunjungUtomo Жыл бұрын

Before I internalized the values of outcome-driven development, I always tried to condition my team to have 2 weeks sprint or shorter, but after that, I almost always gave the team 3-4 weeks because I realized developers require enough time to deliver customer fit increments

@baertheblader9402 Жыл бұрын

I would really appreciate a response. The challenge we always face is that sometimes a sprint has many goals. We know what features need to be implemented in the sprint, so we try to come up with a goal that ties them all together, but what’s the point? I get the “feature factory” is a negative term, but sometimes there is just things that need to be done. For example: we are building an internal app that tracks employee licenses. We had a customer issue where supervisors needed to know whether an expiring license on the report was required for the employees current role, or if it is no longer needed. The solution was to add job title information to several reports. This outcome was valuable and it was easy to implement, so it quickly rose to the top of the backlog. It took one developer one day to do. We have two week sprints. We have many more user stories that are also valuable and they have nothing to do with solving this particular problem. So how do we craft a unified sprint goal when we hope to complete multiple small features in a single sprint?

@scrummasterinblack Жыл бұрын

Thanks for the question. You should start with an outcome driven goal first during Sprint planning rather than creating the goal as an after thought. That's what I meant how in Scrum we start with the why first. The Sprint goal should answer the why. I usually turn the team away from looking at their Product backlog during Sprint planning, as that is some of the reason why the Sprint goal becomes an afterthought. After creating the goal, we select the PBIs that are related with that Sprint goal. Check this video to have an overview of the flow of Sprint planning kzfaq.info/get/bejne/qtKhosiImpyUiXU.html My rule of thumb is, 80% of the PBIs selected should be related with this customer outcome. Having the remaining 20% work not related to this Sprint goal, i.e bug fixing, support work, etc, IMO is still acceptable. But if it is the other way around, the team with the Product Owner need to have hard discussion during Sprint retrospectives. There could be many reasons why they ended up as feature factory. Maybe they don't even have a Product goal and product vision. If that is the case, the whole Scrum team should have a session to define their product vision and product goal.

@vinnier8774 Жыл бұрын

Can you also share how we can change the status quo as Product owner?

@LeighFish Жыл бұрын

Hey Josh, thanks for all your valuable input and teachings. Question: what happens when the sprint has more than 1 focus ie. bugs, and more than 1 feature focus plus code review? How can the sprint goal only be 1 sentence then? Can you give me an example of how best to handle this in order to keep focused on these moving pieces?

@scrummasterinblack Жыл бұрын

Hi Leigh. As mentioned on the video, the Sprint goal should not be about the list of things (defects, features, etc) to be completed otherwise the team will just be a feature factory. The Sprint goal should be about business outcome. Because as mentioned on Scrum Guide, during Sprint review, these outcomes will be evaluated. Watch this video to help you understand the differences between outcome and output kzfaq.info/get/bejne/bK9ngNWYz9Sqf5c.html

@magdalenerosales507 Жыл бұрын

Hi Joshua! Thanks for this video and we will try this outcome-based sprint goal setting. What if the goal needs 2-3 sprints before it can be released, can we keep the same sprint goal until it is met? Appreciate your response!

@scrummasterinblack Жыл бұрын

Thanks Magdalene for the question. You may want to add additional column after released column, called validation. Something like shown on this scene (pause the video to read it) kzfaq.info/get/bejne/mbKFjMt6qJfXkp8.html So every Sprint Review you shall validate whether the goal from 2-3 sprints ago has been met. HTH. I will probably make a specific video about this in the future.

@rejekiramadhan 10 ай бұрын

Halo Permisi Pak Jo izin konsultasi, dari contoh template sprint goal Anda ada kalimat "this will be validated..." hal ini susah dilakukan oleh tim kami karena sering kali scrum tim saya berhasil merilis increment ketika h-1 dan bahkan hari terakhir sprint. sehingga data analytic-nya belum muncul. apakah hal ini bisa dibilang tim kami berhasil meraih sprint goal? dan apakah next sprint bisa langung kami mulai dengan sprint goal baru sambil scrum team memantau metric dari sprint goal sebelumnya? solusi yang saat ini saya coba terapkan adalah memastikan developer tidak mengambil backlog >= capacity mereka sehingga ada waktu bagi mereka untuk melakukan backlog refinement untuk next sprint dan memvalidasi outcome metric dengan metode usability testing (saya pinjam dari ilmu UXR)

@scrummasterinblack 10 ай бұрын

Kalau baru rilis H-1 dan angka outcome belum keluar ya tentunya Sprint goal belum tercapai. Coba pakai Sprint yang lebih panjang (mis. 3 minggu / 1 bulan) dan pada saat Sprint Planning timnya juga harus mempertimbangkan pekerjaan untuk validasi juga bukan sekedar mengejar jumlah product backlog yang harus dikerjakan. Jangan rilis H-1. Timnya juga harus mulai belajar teknik-teknik DevOps dan continuous delivery agar bisa rilis beberapa kali dalam satu Sprint.

@rejekiramadhan 10 ай бұрын

@@scrummasterinblack Halo pak Jo saya mau berkabar outcome dari video yang Anda buat, saya sudah coach C level untuk sprint planning dan sprint review yang lebih outcome oriented dan mereka setuju untuk memperpanjang sprint length, terima kasih banyak atas inspirasinya selama bertahun2, terus ngonten dan selalu sehat ya pak! ga sabar mau ikut kelas PSM 2 di Jakarta

@cutflow2 Жыл бұрын

Something is wrong specifically with this video. The subtitles are stacking on top of each other so I cannot clearly see it. Already tried a video before and after this to confirm that the issue is with this video. Anyway you can fix this

@scrummasterinblack Жыл бұрын

Hi. You can turn off the caption from your KZfaq player.