How to handle velocity lagging and new requests?
Hi all, I want to seek advice on the following about velocity lagging and new requests. Thanks!
1. When the velocity is behind expectation (e.g. due to external impediments):
a) if PO comes for this, should SM tell him that the forecast scope can't be promised given its emerging nature? b) if a stakeholder/ manager comes for this, should SM ask him to refer to PO (being PBL owner) for progress of development? c) what SM should do apart from removing impediments?
2. When stakeholders expect to have more feedbacks (i.e. implying potential new requests) after current release, should SM/ PO opts for (#a) reducing sprint length, or (#b) stop sprinting so as to work upon new upcoming requests when arise?
With reference to the following thread, my view is to opt for (#a) to enable faster feedbacks with smaller batch sizes while (#b) might be needed ONLY WHEN the upcoming requests eventually impact the sprint goal. Does this make sense?
https://www.scrum.org/forum/scrum-forum/5817/sprint-length-and-consistency-same-product-backlock
1. The PO should care about the product value delivered each Sprint and whether or not the team are framing and meeting agreed commitments. Velocity is not product value, and hence a team is unlikely to commit to a velocity or to be expected to do so. The PO should represent stakeholder interests in the value of the Product. The SM, apart from removing impediments, ought to coach the team and the wider organization on the correct application of Scrum.
2. It isn't up to the SM or the PO to adjust Sprint length, although they can suggest it to the Development Team if they believe such a change would be valuable. Stopping sprinting would eliminate a key inspect/adapt cycle and is rarely a sensible option. If more feedback is needed, it would be better to deliver multiple increments during a Sprint and to inspect and adapt progress on that basis. Trailing indicators ought to be minimized where they do not help to close feedback loops in a timely manner.
Thanks Ian for your advice. I want to double check a bit as below:
For item #1, you means "yes" for #a, "no" for #b and "enact Scrum" for #c. Am I correct? Besides, my understanding is that 1) Scrum discourages stakeholders/managers to check development progress, 2) DT owns the development progress & PO owns the value delivery progress, 3) stakeholders should inspect the value delivery progress iteratively during the Sprint before Sprint Review. Is my understanding correct?
For item #2, you mentioned the following in another thread. Is your 2nd point ("shortened if...") applicable in this case?
The length of a Sprint may be:
- increased if a Retrospective reveals the established length to be unworkable, or
- shortened if there is a clear opportunity to consistently reduce batch sizes and deliver increments more quickly.
(extracted from https://www.scrum.org/forum/scrum-forum/5817/sprint-length-and-consistency-same-product-backlock)