I agree with you guys regarding the benefits of a sprint goal. I've seen teams work with and without a sprint goal, what a difference it makes in delivering on PO's expectations. I've found some teams having a difficult time formulating a meanful sprint goal could make use of a helpful reference/template : " Our focus is on . We believe it delivers to . This will be confirmed when ."
I love this video on WHY a Sprint Goal is important. Could you also do a video on HOW to write a good sprint goal (i.e. no run on sentences, focused on value, etc). I have heard you talk about it, but would love to see a video focused on it that I could reference with others.
Thx guys :) I hope your talk about that subject will enlight my teams. I tried, I probably have not found the right word (I missed the point of flexibility) ... let's try with your clarification.
Thanks for the interesting video. My team usually works on very diversified topics as my team acts as a support team to other teams. In that case, my team has quite different topics in single sprint. Sometimes it is really difficult to find a common sprint goal. How to handle this situation?
Hi, I assume your team is kind of DevOps team that in one hand supports other teams (the OP part) and in other hand have development tasks to keep up the environment or automatize (the Dev part). I think you can define an Sprint goal for the second part, the dev part. I would suggest to discuss it with the PO so that the Sprint backlog (top stories in the product backlog) is prioritized in a way that a single Sprint goal can be identified, on which most of the team can work together.
Sprint goals were tough for my previous team. There were multiple major functionalities that were estimated for each quarter. This might have been easier if it was turned into a product line so that there could be one goal for each product line. After development was over, we had bugs which were left over from the Waterfall way of thinking. We (i.e. Agile Coach and myself as Project Manager) tried to get the team to use Scrumban when we went into maintenance, but the powers that be decided otherwise.
Don't you think each of the backlog item needs to state the why we are doing that in the first place? If we are working on very different aspects of Product Vision i.e UX, Connectivity, Features, Bugs etc ... difficult to have a Sprint Goal from the Product Goal itself.
Capacity takes into consideration things like their availabilities for the sprint individually, thier skill level/competence, things like holidays, etc. You have to consider such and more if any as part of velocity. You then realize its not always = velocity
Should multiple scrum teams working from the same product backlog have the same Sprint Goal or should each scrum team have a unique sprint goal? My assumption is that since the Sprint Goal emerges from the Sprint Planning meeting that multiple teams working from the same Product Backlog will have different Sprint Goals.
We have a single list, look for themes in comments/messages/inboxes/classes we get, order the list, and pull from the top. Every now and then a BIG idea emerges or something happens that causes us to add an item that jumps straight to the top. We also validate afterwards what content people engage with and view and try to give more of that. That causes re-ordering or adding new things as well.
Hi. What happens if the testing tasks are not complete before the end of the sprint and every sprint, testing tasks get carried forward. Looking forward to your reply.
