Sprint Goal: Increase velocity: eliminate waste, improve communication, reduce transaction/handover time
hi everyone,
Do you think that a sprint goal can be formulated as "Increase velocity: eliminate waste, improve communication, reduce transaction/handover time", while this is an agreement of the dev. team and the PO. I know that it sounds like a retro item and improvement, but, given that prior to this goal the PO has significantly improved quality of the user stories, and the team helps to make stories complaint to DoR.
Does a Sprint Goal like that reflect the Product Backlog Items you are forecasting to complete?
How do you know if the Sprint Goal is achieved?
Well, just to address the anticipated comments :) that there's no guidance to why the team is building the Increment. Yes, the guidance is not very transparent here, as value of such a goal is to see how much more features/stories the team can deliver with the focus on eliminating waste. Another aspect here, of course, the assumption is that the team will not produce just any random stories to increase velocity - focus on value is remaining.
Ben - these are very valid points, and setting a goal like this may look like mixing up the process and the product. Where the goal is for the product increment. Yet, will try to answer, the goal can reflect that there will be more prioritized PBIs in the and it will be larger(compare to earlier). Knowing if the goal is achieved is easy - if the number goes up - achieved :)
Do you think that a sprint goal can be formulated as "Increase velocity: eliminate waste, improve communication, reduce transaction/handover time"
Do you think this Goal will help you to deliver the increments of highest value ?
Do you think that a sprint goal can be formulated as "Increase velocity: eliminate waste, improve communication, reduce transaction/handover time"
Would that provide satisfactory guidance to the Development Team on why it is building the Increment, and would it be coherent enough to cause team members to work together rather than on separate initiatives?
Do you think that a sprint goal can be formulated as "Increase velocity: eliminate waste, improve communication, reduce transaction/handover time"
I'd like to address some of these, particularly the improve communication goal. I'd agree this could be a great retro action item but I'd encourage you to make sure the team is being deliberate and specific when coming up with this. What needs communicated To whom does it need communicated and when should we communicate it are all very important questions when it comes to things like this. How will the team know it has succeeded in this endeavor? Perhaps they hypothesize that there will be less surprise dependencies if they communicate with another team during refinement.
Same concept with eliminate waste.... what waste does the team seek to eliminate? Are there PBI's associated with this that can be delivered to achieve this goal? What value does this bring to the team or product?
The goal may be to decrease the amount of time a site goes down by X percent. There may be a certain amount of technical debt or waste elimination required in order to meet this goal.
Technically it can be formulated but why would you? I don't consider this to be a good Sprint Goal because it's not clear what the Increment is supposed to be when the Sprint ends. How would it help the Scrum Team prioritize the Product and Sprint Backlog?
Ignoring the context of it for a second, does it serve its purpose as a Sprint Goal?
- Does it allow the PO and Dev team select the appropriate backlog items to build the Sprint with during Sprint Planning?
- Does it gives the Sprint direction and purpose by setting the guardrails for the Sprint for when it's running?
- When the Sprint Review occurs and the team demoes the Increment, would they be able to showcase the completion of this Sprint Goal?
Consider your Scrum Team. If you told their Stakeholders that this Sprint Goal is what the team expects to demo to them, would that be sufficient as it's currently written (assuming that increasing velocity is what they truly cared about)?
"Increase velocity: eliminate waste, improve communication, reduce transaction/handover time"
If I were the stakeholder, I would rather want to know before going into the Demo:
- What waste is expected to being eliminated?
- What communication is expected to improve and at minimum, by how much?
- What transaction/handover time is expected to being reduced and at minimum, by how much?
Thank you for asking the right questions. I think I have a more solid understanding now. Even though it's was clear that having such a goal is a poor idea, yet I could justify such a goal under particular circumstances. Now I am sure there is no need to justify a goal like that - it better to craft a better goal that will suit the circumstances more.